Closed Bug 1019024 Opened 7 years ago Closed 7 years ago

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

Categories

(DevTools :: Debugger, defect, P2)

All
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 33

People

(Reporter: till, Assigned: past)

References

Details

Attachments

(1 file)

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.
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?
Flags: needinfo?(jimb)
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.
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?
Or devtools should move focus out from the content window?
(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?
Flags: needinfo?(jimb)
nsIFocusManager should be able to tell where the focus is.
Thanks for the help, I have a fix for this now.
Assignee: nobody → past
Status: NEW → ASSIGNED
Priority: -- → P2
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
Attachment #8451730 - Flags: review?(rcampbell)
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.
Attachment #8451730 - Flags: review?(rcampbell) → review+
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?
(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.
Yes, exactly.
https://hg.mozilla.org/mozilla-central/rev/a352176e899e
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 33
Blocks: 1037983
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.