[e10s] Shift-Ctrl-I launches GTK3 inspector as well as Firefox inspector

NEW
Unassigned

Status

()

defect
4 years ago
5 months ago

People

(Reporter: roc, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s-, firefox44 affected)

Details

Attachments

(1 attachment)

Fedora 22, gtk3-3.16.6-1.fc22.x86_64.
Steps to reproduce: Press shift-ctrl-I in Firefox.
Expected results: Fx devtools inspector opens.
Actual results: Fx devtools inspector opens *and* Gtk3 Inspector opens.
Bug 1208293. Suppress GTK3 Inspector opening by handling enable-debugging signal. r=karlt
Attachment #8665744 - Flags: review?(karlt)
Depends on: 1195002
Comment on attachment 8665744 [details]
MozReview Request: Bug 1208293. Suppress GTK3 Inspector opening by handling enable-debugging signal. r=karlt

https://reviewboard.mozilla.org/r/20313/#review18277

I don't think this is a good fix, thanks.

Whether enable-debugging is sent depends on what OnKeyPressEvent() returns.

If the devtools inspector binding is not calling preventDefault on the event
or we don't have nsEventStatus_eConsumeNoDefault for some other reason, then
that should be fixed at its cause.

This workaround would disable the GTK3 inspector for any keybinding
(not just C-S-i) and the inspector may be useful for debugging Gecko.

This bug will actually get fixed by bug 1195002 because OnKeyPressEvent() will
always return TRUE, but now that I see that GtkWindow has its own key bindings,
I'm wondering whether returning TRUE for unhandled events is really a good
idea.
Attachment #8665744 - Flags: review?(karlt)
enndeakin: should the XUL commands defined in browser-sets.inc via <command>, <broadcaster> and <key> --- such as Tools:DevToolbox --- trigger preventDefault? It seems to me they should, but as far as I can tell, they don't.
Flags: needinfo?(enndeakin)
The inspector is disabled by default in 3.18 for this reason:
https://git.gnome.org/browse/gtk+/commit/?id=9326f1a57c52cc991b5756d1811155a25fe6623c
STR:
1. enable e10s.
2. Load page which uses content process. e.g. https://bugzilla.mozilla.org/
3. Click on content page to focus.
4. S-C-i.

When chrome is focused or e10s is disabled, we have nsEventStatus_eConsumeNoDefault as expected.  With e10s and content focus, we have nsEventStatus_eIgnore.
Component: Widget: Gtk → Event Handling
Summary: Shift-Ctrl-I launches GTK3 inspector as well as Firefox inspector → [e10s] Shift-Ctrl-I launches GTK3 inspector as well as Firefox inspector
kicking back to e10s triage.
Flags: needinfo?(enndeakin)
roc, do you feel this should block e10s?
Blocks: dte10s
tracking-e10s: --- → +
Flags: needinfo?(roc)
No. As Karl said, bug 1195002 works around this bug so there isn't a problem on trunk.
tracking-e10s: + → ---
Flags: needinfo?(roc)
tracking-e10s: --- → -
Assignee: roc → nobody
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.