Before e10s, gmail was able to catch this key and set the focus to the search window. Now, it pops up our search UI.

Move old M2's low-priority bugs to M6 milestone.

I get the following event flow when I try this: 1. Keydown event is received from widget 2. Keydown event listener on parent (browser.xul) is called. 3. EventStateManager::DispatchCrossProcessEvent is called with the keydown event 4. Keypress event is received from widget. 5. TabChild::RecvRealKeyEvent is called with the keydown event. Step 5 happens from within the call to DispatchWidgetEvent in RecvRealKeyEvent. 6. Keypress event listener on parent is called. One of these listeners opens the findbar. 7. Keydown event listener on child page is called, and cancels the event, but it is too late to cancel the findbar opening I'm guessing that something similar to bug 862519 will be needed, as that looks to have only handled <key> elements, but I'm not familiar enough with the event system here to know for sure.

FWIW, I can also reproduce this with noVNC (https://github.com/kanaka/noVNC) -- Before e10s, '/' would just be handled by noVNC and get sent to the VNC server properly. However, in e10s tabs, '/' does not get sent to the VNC server, which almost completely breaks functionality for VNC sessions with Linux terminals open.

I see the same now on Linux with Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20141214030205 CSet: f14dcd1c8c0b

Note to self: make sure to check that the solution fixes bug 1135502

Nothing deep going on here -- the preventDefault test was in the wrong place. WRT comment 12, this does fix that issue as well. Tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=56ee3ba1a9a2

PS: As part of the STR, you have to turn on gmail keyboard shortcuts. In GMail: Settings -> General Tab -> Keyboard Shortcuts -> Turn Keyboard Shortcuts On See https://support.google.com/mail/answer/6594?hl=en

Reproduced this bug by following the STR in windows 7, 64 Bit with Nightly 34.0a1 (2014-08-29) The bug's fix is verified on Latest Nightly 42.0a1! Build ID 20150708030204 User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

I have successfully reproduced the bug by following STR in Nightly 34.0a1 (2014-08-29) on Linux x64 The bug is fixed on Latest Nightly 42.0a1 (2015-07-11) Build ID: 20150711030210 User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0