Comment 1 Samuel Mannehed 2022-10-07 14:42:36 CEST

The mouse-interaction part of this was fixed in r38984 (should probably have been its own commit) for bug 7908. This commit also added a white (slightly transparent) obscuring layer above the session when the fallback error dialog shows.

However, keyboard interaction is still possible, so that's the remaining issue to be solved here.

Comment 2 Samuel Mannehed 2022-10-07 14:59:39 CEST

This was fixed upstream in noVNC in e1f8232bc90c77e5746f6f8356613962021cc862

Comment 5 Samuel Mannehed 2022-10-10 15:35:54 CEST

This has been fixed now. Now it should not be possible to interact with the session or the rest of the GUI, using either the keyboard or the mouse, while this error is showing.

Note that interactivity was blocked in r38978 (for bug 7908) on the login page while showing the "JavaScript is disabled"-error.

Comment 6 Samuel Mannehed 2022-10-12 13:16:21 CEST

Part of the new code resides in our error handler, which is the code that runs if other parts of Web Access causes an uncaught JavaScript exception. This means the error handler code needs to be very robust.

If the error handler itself causes an exception, we fall back on using “document.write()” which means the user won't get a pretty error dialog. That might be a bit harsh for the new code that disables interactivity when considering its minor implications.

Let's use a best-effort approach to the new code, we don't have to give the user a worse experience if it fails.

Comment 9 Samuel Mannehed 2022-10-12 13:31:55 CEST

(In reply to Samuel Mannehed from comment #6)
> Part of the new code resides in our error handler, which is the code that
> runs if other parts of Web Access causes an uncaught JavaScript exception.
> This means the error handler code needs to be very robust.
> 
> If the error handler itself causes an exception, we fall back on using
> “document.write()” which means the user won't get a pretty error dialog.
> That might be a bit harsh for the new code that disables interactivity when
> considering its minor implications.
> 
> Let's use a best-effort approach to the new code, we don't have to give the
> user a worse experience if it fails.

This has been fixed now.

Comment 10 Pierre Ossman 2022-10-14 12:22:34 CEST

Tested on RHEL 9. Compared 4.14.0 with build 2862. Tested using Firefox 102 ESR and Chromium 105.

> * Errors shown when JavaScript is disabled or when JavaScript errors occur while connected should appear on top (in front of all other elements).

Yup. It is in front of the session, the control bar, clipboard panel and status bar.

> * When these errors are shown, it should not be possible to interact with the rest of the Web Access page using a keyboard, mouse, or a touch screen.

Yup. On 4.14.0 I can still interact with the mouse and keyboard with both the session and the control bar. But with the current build I am unable to get interaction:

 * Mouse events don't do anything
 * Touch events don't do anything¹
 * Keyboard events don't make it through

¹ Only tested using touch emulation in Firefox and Chromium

> * When these errors are shown, it should not be possible to give focus to other elements (for example buttons or input fields) using the keyboard.

Yup. I can't Tab to reach neither the session nor the control bar.