User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41 Steps to reproduce: 1. Open a webpage with JS code addEventListener('keydown', function(e){ console.log(e.keyCode); if(e.keyCode == 114 || e.keyCode == 118|| e.keyCode == 121|| e.keyCode == 122 || e.keyCode == 18){ console.log('prevent'); e.preventDefault(); } }, true) 2. Press keys listed in if() parenthesis Actual results: Some keys ignore e.preventDefault. (F7 - 118; F10 - 121; alt - 18) Other keys are prevented from running their default action (F3 - 114; F10 - 122) Expected results: All keys should have been prevented from running their default action. Or is it an intended change in Firefox 48?

Sorry, bad diagnosis again,

Sorry, bad diagnosis again, it seems to just affect multiprocess windows in e10s...

Using F7 as an example (implemented as a system keypress <handler> in browser.xml), this handler is called before the keydown listener on the page. Masayuki should be able to investigate this.

Hmm, I'm working on similar bug of <key> elements at bug 1257617. However, I have no idea to do similar fix for normal key event handler of JS. I guess that we need to add an API to wait a reply from content process and listen "test keydown" event which will be added by bug 1257617.

I recommend that if it's possible keyboard event handlers in chrome should use XUL <key> elements as far as possible. Using normal keyboard event listeners will increase the implementation cost.

Both <key> elements and <handler event="key..."> go through nsXBLWindowKeyHandler so we should be able to have the same or similar fix for both no? Also, I didn't investigate the other keys mentioned in this bug (F10 and Alt) which I suspect has to do with the way accesskeys and menus have a complex interaction.

(In reply to Neil Deakin from comment #6) > Both <key> elements and <handler event="key..."> go through > nsXBLWindowKeyHandler so we should be able to have the same or similar fix > for both no? Oh, really? If so, it's very good news to me. Then, this must be fixed by bug 1257617 too.

F10 key will be fixed by bug 1347351.

Hmm, I can confirm the Alt key issue. But I cannot reproduce F7 key issue. Was the implementation was changed?

Okay, we should treat only Alt key handling here. Please file a new bug if you still see this bug with F7.

Comment on attachment 8886634 [details] Bug 1292053 - nsMenuBarListener::KeyDown() and nsMenuBarListener::KeyUp() should wait reply even from remote process if it's necessary Canceling the review until fixing bug 1292053.

Comment on attachment 8886634 [details] Bug 1292053 - nsMenuBarListener::KeyDown() and nsMenuBarListener::KeyUp() should wait reply even from remote process if it's necessary This caused the new orange. Sorry for the bug spam.

Masayuki, this is the bug I mentioned yesterday about not being able to prevent Alt from triggering the menu, even on keyup.

Ah, I forgot this bug...