It seems setting an antivirus exemption for httpd and mysqld seems to resolve the problem for now (note: client and web server and db server are one and the same computer using XAMPP).

Also see this link: https://docs.bitnami.com/installer/faq/windows-faq/configuration/configure-antivirus-windows/#disable-execution-scans

Other things to look at are giving explicit firewall exclusions for localhost and also setting the browser (in my case Firefox) to NO PROXY.

Probably it was the antivirus setting that helped to resolve the issue.  Was using Gravity Zone End Point Protection and set it to scan all processes aggressively.

Although session data is stored on the server, FA chose to store the session id as a cookie on the browser, rather than in the URL.  Both mechanisms can be vulnerable to session stealing, and FA has code to detect it, perhaps by looking at the ip address.

Running Chrome in incognito mode could be the source of the problem, because it will not store the session id cookie.   See, https://stackoverflow.com/questions/30475878/remembering-php-session-private-browsing.   The selected answer of the question makes a suggestion that a session id could be forged from other server data, but I do not know if FA does that (I doubt it).

My suggestion on clearing browser cache/cookies was to clear an old session id.  I doubt that this would fix anything, but just worth a shot.

FA already makes extensive use of POST data including hidden fields.  I am guessing that the reason why cart was not one of them (coded into SESSION)  is because an array is not straightforward to code in this manner, which is why I had to add the serialize/unserialize functions.    I am of the opinion that coding the cart into POST data is preferable to SESSION data and solves the multiple tab problem.  It eliminates the error message in question and use of the configuration override which could cause other problems.

I want to put in some more question to this post just to have more clarity.

You have indicated a scenario where the end user intentionally opens multiple windows or tabs (for different business processes) and by consequence runs into the technical issue.

Let's compare this with what I have observed.

The technical issue that I have encountered is happening even if running Chrome in incognito mode (thus no cache) and there is only 1 one window with 1 tab open and the first action that I am trying to do is a direct invoice immediately after login.

Further more, the technical issue is most often encountered with Chrome and rarely with Firefox.

As such, could it be that the technical issue that I am encountering is different from what you have described but with a few overlap (similar behaviour and error messages).

Next, I want to check if it will help to tinker with the php.ini inside XAMPP folder.  Specifically those having to do with server caching settings (not very sure if the caching eventually ends up on server side or the client browser side) (*client and server are one and the same computer*).

Sidenote #1: I only have a lesser than basic knowledge with PHP, sorry.

Sidenote #2: I think the edit check (for other open FA window and tabs) might be a relevant feature to have.

Noted with thanks.

Had a look at the mantis page link.

I will be doing the edit to config.php for now.  Many thanks for the input.

Will also use Firefox just to be on the safe side.

Best regards,

Kanay

I'm guessing no, because the only thing stored in the browser is the session cookie.   If this happens again, you might suggest to the client to clear the browser cache and try again.

My opinion is that storing page operational data in a php session rather than post is bad practice because session is browser wide and poses conflicts with multiple tabs  It seems to be a common practice, but one easily avoided.  In the aforementioned bug report, all I did was search and replace SESSION with POST, add a hidden cart variable to the form and because the cart was an array, I also had to serialize and unserialize it.  So while the bug fix is conceptually simple, it did hit a large number of lines.  This fixed the multiple open tab problem for sales, purchasing, and banking.  This was essential because often a clerk is reviewing one sales order/purchase/bank transaction in one tab and entering another in another tab.  Indeed, I am surprised that no one else complains about this in vanilla FA.

Do I still need to set the above mentioned Syspref variable to 1?

Noted with thanks. Will try the change in settings on config.php .

I am not able to access http://mantis.frontaccounting.com as I do not have login access to that.

Please assist to copy and paste the information from there and into this forum post.

Best regards,

Kanay

   /* No check on edit conflicts. Maybe needed to be set to 1 in certains Windows Servers */
    $no_check_edit_conflicts = 1;

Or change the code to allow multiple open tabs by replacing session variables (see, http://mantis.frontaccounting.com/view.php?id=4664).

This edit session has been abandoned by opening sales document in another browser tab. You cannot edit more than one sales document at once."

But the problem is that this doesn't always occur so I am still unable to find the reason

I regularly get this error message when attempting to do direct invoice.

"This edit session has been abandoned by opening sales document in another browser tab. You cannot edit more than one sales document at once."

The error shows even when there is no other window or tab opened with FA.

Was running FA 2.4.6
OS is Win 7 Pro
Chrome (updated) (regular occurrence of error)
Firefox (extreme rare occurrence of error)
Initially running PHP 5.6.40 (from XAMPP) (error happens)
Switch to PHP 7.3.9 (from XAMPP) (to troubleshoot but error still happens)
Installed FA 2.4.7 (error still happens)

I can't consistently replicate the error and when I click around the interface to recreate the same error, i encountered another issue.  The log in instance does an uncommanded log out (in Chrome) .

So now I have 2 issues: Session abandoned and uncommanded logged off.

Additional info: Just prior to uncommanded logoff, there seems to be a Chrome windows that pops up and offers to translate the page (Chrome built in page translate).

I am not able to make sense out of it as everything was more or less okay for the past few years.  These started happening in August 2019.

There was no significant change done to the FA system just prior to the errors showing up.

Could this be due to any of the following?

Windows updates?
Chrome updates?
Chrome change of theme from default to something else?
Character encoding in db?
Using wrong character encoding when doing restore backup through myPHPadmin?

I hope someone can help to make sense of these.

Best regards,

Kanay