1019024 - Focussing a tab with a paused debugger disables all keyboard input.

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Till Schneidereit [:till]]

When, during a debugging session, going to another tab and then back to the one with the debugger, keyboard focus is completely in the winds: not only doesn't the debugger listen to keyboard input: no keyboard shortcuts work at all. That means it's not even possible to activate a different tab with Cmd/Ctrl+{1-9}, or the location bar with Cmd/Ctrl+l. Clicking on the debugger panel or the location bar, or selecting a different tab with the mouse are the only ways to get out of this state.

Comment 1

[Rob Campbell [:rc] (:robcee)]

that's troubling, but not sure we can do much about it with a paused debugger. We've hoisted all our event handling in a nestedEventLoop and that applies to everything in the same process.

Jim, do you think we could modify the nestedEventLoop to allow keystrokes not under debuggee control to pass through?

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

When execution is paused we call suppressEventHandling() in the content window, so either the key event handlers are set there (and not in the chrome window) or that call interferes with the bubbling of the event. smaug may know more.

Comment 3

[Olli Pettay [:smaug] (away May 1 - 8)]

If you call suppressEventHandling on a content window and focus is there, key events can't be dispatched since they are dispatched to the focused element.

Sounds like we need some different setup. Dispatch events to chrome event handler when
devtools suppress event handling?

Comment 4

[Olli Pettay [:smaug] (away May 1 - 8)]

Or devtools should move focus out from the content window?

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Olli Pettay [:smaug] from comment #3)
> Sounds like we need some different setup. Dispatch events to chrome event
> handler when devtools suppress event handling?

I assume that this would require changing the way suppressEventHandling works or providing a new similar method, right?

(In reply to Olli Pettay [:smaug] from comment #4)
> Or devtools should move focus out from the content window?

That sounds easier to my inexperienced ears, but how could the debugger frontend detect that the paused content window is focused after returning from another tab (so that it can then focus the devtools iframe)? Normal addEventListener methods wouldn't work, right?

Comment 6

[Olli Pettay [:smaug] (away May 1 - 8)]

nsIFocusManager should be able to tell where the focus is.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

Thanks for the help, I have a fix for this now.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: When the page is paused, send all keyboard events to the debugger frame

I think it turned up pretty straight-forward: coming to the paused tab, either through direct selection or via closing another tab, will trigger a TabSelect event that we can use to focus the debugger frame (after waiting a tick for the content focus event to be delivered first).

Try: https://tbpl.mozilla.org/?tree=Try&rev=72fae256c2e4

Comment 9

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 8451730 [details] [diff] [review]
When the page is paused, send all keyboard events to the debugger frame

Review of attachment 8451730 [details] [diff] [review]:
-----------------------------------------------------------------

alright Mr. Astithas. You win this round.

Comment 10

[Victor Porof [:vporof][:vp]]

Comment on attachment 8451730 [details] [diff] [review]
When the page is paused, send all keyboard events to the debugger frame

Review of attachment 8451730 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/debugger/panel.js
@@ +44,5 @@
>      if (!this.target.isRemote) {
>        targetPromise = this.target.makeRemote();
> +      // Listen for tab switching events to manage focus when the content window
> +      // is paused and events suppressed.
> +      this.target.tab.addEventListener('TabSelect', this);

Is this available in a browser toolbox?

Comment 11

[Victor Porof [:vporof][:vp]]

(In reply to Victor Porof [:vporof][:vp] from comment #10)
> 
> Is this available in a browser toolbox?

I guess it doesn't really matter since this code path isn't exercised since targets are already remote in that case.

Comment 12

[Panos Astithas (he/him) [:past] (please ni?)]

Yes, exactly.

Comment 13

[Panos Astithas (he/him) [:past] (please ni?)]

https://hg.mozilla.org/integration/fx-team/rev/a352176e899e

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a352176e899e