We are experiencing an intermittent bug, so I can’t report it because I haven’t figured out how to consistently reproduce it. Has anyone else experienced the following issue or similar?
ERPNext: v13.18.0
Frappe Framework: v13.17.1
My Machine Specs:
Chrome Version 102.0.5005.115 (Official Build) (64-bit) on Windows 10 Pro 19044.1766 with Windows Feature Experience Pack 120.2212.4180.0.
Josh’s (Colleague) Machine Specs:
Chrome Version 102.0.5005.115 (Official Build) (64-bit) on Windows 11 Insider Preview 25140.1000 (rs_prerelease)
Description of Issue:
Josh and I were sharing the “Bob Test” account user for testing. Its a relatively basic account with roles “Employee”, “Employee Self Service”, and “Manufacturing User”.
I logged into the Bob Test account user.
I created a new Expense Claim. I could not edit the Expense Details records. Clicking an Expense Claim Detail column showed a popup that says “Editing Row 1”, but the dialog was blank with no input fields. I couldn’t edit the columns directly in the Expenses table either (clicking one was showing the blank dialog).
I thought the issue was permissions-related so I reported it to Josh and we visited the issue the next morning together. He wanted to reproduce before changing anything so we both logged in with the same Josh Test user from our separate machines.
He logged in from a Chrome incognito instance.
I logged in from a regular Chrome account instance.
We both went to create Expense Claim. He was seeing the glitch I had seen the previous day. However it was working correctly for me this time!
He clicked the Reload option to clear Frappe cache. He tried to create a new expense claim again, and had the same glitch.
He opened Edge (was previously testing Chrome incognito). He logged in with Josh Test and created new Expense Claim. He could edit fields correctly.
He opened a new regular Chrome account instance and tested and it worked correctly as well.
He closed the incognito instance and opened a new one and it worked correctly as well.
The behavior leads us to believe that the glitch is tied to either session cookies or some javascript that isn’t getting reloaded whenever a Reload action is taken.
When the behavior is experienced again, a suggested course of investigation is going to the browser developer console and investigating what cookies are set by the site and trying to delete cookies one-by-one to see if any of it fixes the issue. Another possibility is to investigate what javascript objects are loaded and try deleting them.
Neither angle of investigation is very good. Its getting deep in the weeds and simply deleting something doesn’t necessarily communicate the broken program behavior.
Can anyone provide some testing ideas or thoughts on what the cause could be?