Great find Corey! It looks like they added the fix to 84.0.4147.38 and it was marked stable/released last night as version 83.0.4103.116.
My desktop was updated last night and I haven't been able to reproduce the issue yet. But with how sporadic the issue was, I'm not positive it is resolved.
Anyone else updated and able to verify?
We are still experiencing the issue with the 83.0.4103.116 version of Chrome.
Update for you all. We've identified the code path that results in this issue, and it is being tracked internally as ARCHER-93653. If you are experiencing this issue, please Open a Support Case and reference both this discussion thread and our internal ticket ARCHER-93653.
The issue stems from defect in Chromium that creates a race condition between a GET and a POST that occur when clicking the ellipses to generate the pop-up. If the GET runs too slowly that it hasn't finished before the POST is sent, the issue occurs. This explains why the issue is intermittently experienced by most. The fix will come in the form of a change to Chromium (see next paragraph).
We have confirmed in-house that Chrome Canary 85 (the current developer build of Chrome) does not exhibit this behavior, however that release isn't slated for production until August 25. The fix that is in 85 was also put into 84 and 83, but for some reason it is not working there. Communication with Microsoft and Google is ongoing.
Another option for workaround is to leverage something other a values pop-up configuration for these fields. It is understood that this is no small amount of effort or change to put in, and will not be a viable workaround for most, but it is important to put it out there as an option.
We additionally need to gather the impacted environments to produce fixes. So far I have:
- Sirisuda Taylor - 6.7 P4
- Unal Perendi - ???
- Jonathon Ronna - 6.4 P2
- Ilya Khen - 6.7 P4, P5, and P6
- Shaun-Martin Lawless - 6.8 P1
- Brian. Dejno - 6.6 P3
- Douglas Campbell - 6.6 P3
- Michael Scruggs - 6.7 P4
- Corey Brown - 6.4 SP1 P1, 6.7 P4
- Margo Brosnan - 6.6 P6
Please respond with your Archer version if it is not listed above.
Thank you for the follow up Scott,
We saw this issue in 6.4 SP1 P1 (6.4.10100.1051)
as well as in version 6.7 P4 (6.7.00400.1036)
That's great news Scott, thanks for digging into this deeper on the RSA side even though it is a Chrome issue.
We are on 6.6 P3 here.
Scott Hagemeyer, Again, thanks for the efforts to address this situation. Would it be remotely possible to offer the fix as a manual change to an .aspx file (or other files) instead of performing an upgrade? #whenyouwishuponastar
The current plan is to offer remediation to 6.8.x.x and 6.7.x.x in the form of the next CPR, which will be 126.96.36.199 and 188.8.131.52, respectively, and targeted delivery for both is 2 July.
For the remaining supported versions (6.3.x.x, 6.4.x.x, 6.5.x.x, and 6.6.x.x), upgrading to 184.108.40.206 or 220.127.116.11 is the method of remediation. Recognizing that upgrades spanning multiple minor releases aren't always able to be executed quickly, we are also evaluating creating on a case-by-case basis patch specific DLLs which can be swapped out on the servers. All users will need to then clear their browser cache to get the new DLL with the fix pulled down, unless we can quickly determine a way to bust the cache with the new DLL automatically.
Let's not be too harsh on Chromium.
After all, what appears to have happened is that a defect with Chromium exposed one with Archer. Like 'Inception', but with risk management software.
Scott Hagemeyer, good points raised as usual from you. And the reference to Inception was epic! The question is which dream/timeline are we in and how much time do we have left?