seb-win-refactoring

seb-win-refactoring copied to clipboard

If you use SEB to view a page that uses WebRTC to record audio, it is not possible to use the Ctrl+Q quit shortcut while the microphone is captured (upon pressing Ctrl+Q, nothing happens). Once the microphone is released Ctrl+Q becomes available again.

You can easily reproduce it using this demo page.

• Set this page as the start page in SEB
• Once the page loads, try using Ctrl+Q and observe that it works.
• Now press "Start Recording" and observe that while recording Ctrl+Q does not work.
• Press "Stop Recording" and observe that Ctrl+Q still does not work.
• Press "Release Microphone" and observe that Ctrl+Q works again.

This can be reproduced in the latest SEB 3.4.0 and also 3.3.2 (likely to exist in all versions since the introduction of WebRTC support).

The obvious workaround is to ensure that the bottom toolbar of SEB is enabled so that there's a visible "Quit" button to press, removing the need to use the shortcut. However this is not always desirable as the toolbar takes up some screen space.

The reason this causes us a problem is because we have a "Speaking" test where the microphone is captured for a relatively long time, and during this time it is not possible to quit SEB (unless we enable the toolbar, which we ideally don't want to do).

You could also use a quit link placed somewhere conveniently on your web page as a workaround.

We'll need to investigate the problem, but I suspect this to be an issue in the browser engine. Did you test whether the action center works? It can be activated via WIN+A and would provide another option to quit SEB.

No, action centre doesn't work either. Win+A works when the microphone is not in use, but doesn't work when it is,

I think the issue seems to be that the key handler in KeyboardHook.cs doesn't work correctly / isn't hit while the microphone is active in CEF, which would explain why none of the usual shortcuts work. Key events are still raised as expected via KeyboardHandler.cs (which captures keyboard events in CEF itself) but that isn't enough because I think the shortcuts like quit, action centre etc. are not handled from there.

Exactly, they are handled via low level monitoring of the keyboard. This incidentally also was one of the issues we had initially resp. why we couldn't activate WebRTC with the first release of SEB 3.x (see #3 and/or https://bitbucket.org/chromiumembedded/cef/issues/2609/chomium-windows-when-using-own-low-level).

This very much looks like a regression in the upstream CEF or Chromium codebase. Looking at the issue from CEF linked above, I just noticed that it is still set to "won't fix" even though WebRTC used to work fine since we activated it, at least until now. We'll see that we can investigate the issue (certainly before the release of version 3.5), at the moment we're unfortunately quite busy with other priorities.

Due to a change in priorities, we won't be able to investigate the issue for the upcoming release version 3.5.0. Have there been any further insights in the meantime @chrisswan-rm?

@dbuechel thanks for letting me know. No, we haven't looked into this further; we have told our client that this is a limitation for now (that they cannot use Ctrl+Q to quit when on a part of the exam that uses audio recording).

Okay, thanks for the feedback. Then we'll leave this open so that we'll hopefully get around to having a look at it for version 3.6.0, albeit that I highly suspect this to be a bug / regression in the browser engine as mentioned above.

Thanks again for your report and sorry for the delayed tackling of the issue. I am able to reproduce the issue as reported by you above, but am afraid that this very much appears to be a regression somewhere in the browser engine (be it Chromium itself or the Chromium Embedded Framework CEF).

Thus, I currently don't see any option other than waiting and hoping for the best (i.e. that the regression is fixed in the engine asap). Please let me know if there is anything you'd like to investigate further, I'll certainly leave the issue open for now but mark it accordingly as framework bug.

This issue is stale because it has been open for 28 days with no activity. It will soon be closed automatically if there are no updates.

This issue was closed because it has been inactive for 14 days since being marked as stale.