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

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: MozReview Request: Bug 1208293. Suppress GTK3 Inspector opening by handling enable-debugging signal. r=karlt

Bug 1208293. Suppress GTK3 Inspector opening by handling enable-debugging signal. r=karlt

Comment 2

[Karl Tomlinson (:karlt)]

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.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 4

[Alexander Larsson]

The inspector is disabled by default in 3.18 for this reason:
https://git.gnome.org/browse/gtk+/commit/?id=9326f1a57c52cc991b5756d1811155a25fe6623c

Comment 5

[Karl Tomlinson (:karlt)]

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.

Comment 6

[Tracy Walker [:tracy]]

kicking back to e10s triage.

Comment 7

[Jim Mathies [:jimm]]

roc, do you feel this should block e10s?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No. As Karl said, bug 1195002 works around this bug so there isn't a problem on trunk.