User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161115075801 Steps to reproduce: This is related to a few other open bugs here, notably bug 1052569, which is where I was referred from. Reproducing this does, unfortunately, require an account on avclub.com's commenting system, which is Disqus. I have reproduced this on Firefox 50 in Safe Mode (running on Linux). 1) Ensure that you're logged in to the comments at avclub.com, so your username appears in the upper-right-hand corner of the comment block with a "quote" graphic next to it. 2) Visit an article at http://avclub.com/, for instance: http://www.avclub.com/review/two-new-books-explore-artistry-film-master-244710 3) Scroll down to the comments area 4) Click on the "quote" graphic next to your username - this will bring up a Disqus sidebar showing your recent replies, etc. 5) Close the sidebar by clicking on the "X" Actual results: At that point, trying to hit "Ctrl-W" to close the tab will fail. I do admit this does not happen 100% of the time, but I'd say at least 95% of the time it does. Sometimes hitting Ctrl-W multiple times eventually works, and sometimes clicking elsewhere on the page will cause Ctrl-W to start working again. Expected results: I'd expect Ctrl-W to close the tab regardless of what the page has done.

I can reproduce this on OS X with current beta (beta 51) as well. On Nightly, I can reproduce when e10s is turned off. This is quite odd - it seems to me that all shortcuts are blocked / not working, including tab switching and the like, when they really shouldn't be. Masayuki or Felipe, can you take a look? Maybe it's a focus problem or something?

Although, I don't test this yet, only on Linux, we don't support the feature when plugin has focus due to native event model limitation (bug 1257761). However, if you reproduce this with OS X, Cmd+W, there is a bug...

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #2) > Although, I don't test this yet, only on Linux, we don't support the feature > when plugin has focus due to native event model limitation (bug 1257761). > > However, if you reproduce this with OS X, Cmd+W, there is a bug... Right, but also, I don't see any plugin icons in the location bar on current (OSX...) nightly on the page in question, so I don't think it's that.

(This code has changed significantly since I worked on it, so I'll let the investigation for Masayuki)

Okay, I reproduce this bug and odd, I cannot do any keyboard navigation after that.

> 4) Click on the "quote" graphic next to your username - this will bring up a Disqus sidebar showing > your recent replies, etc. Hmm, I become not be able to open the sidebar, instead, new tab is opened with https://disqus.com/home/inbox/? Why??

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #6) > > 4) Click on the "quote" graphic next to your username - this will bring up a Disqus sidebar showing > > your recent replies, etc. > > Hmm, I become not be able to open the sidebar, instead, new tab is opened > with https://disqus.com/home/inbox/? Why?? Not sure. I can still reproduce. Maybe Disqus are A/B testing something or other... Does it work in a clean profile? Is there anything I can check in order to move forward with investigating what's broken here?

(Although, I'm still on vacation) I'm thinking that this is focus problem. I'd like to check what happens in nsFocusManager after the sidebar is closed. However, when I try to check it with debug build, I couldn't open the sidebar, sigh...

(In reply to Masayuki Nakano [:masayuki] from comment #8) > (Although, I'm still on vacation) > > I'm thinking that this is focus problem. I'd like to check what happens in > nsFocusManager after the sidebar is closed. However, when I try to check it > with debug build, I couldn't open the sidebar, sigh... I tried to get a NSPR log of the focus code but didn't find it very helpful because I couldn't identify when what happened. Using some JS, though, it seems that after clicking the close button, which is an <a>, that button is focused. However, that button is in a frame (the disqus iframe) which by the time you try and hit a shortcut, has display: none. So presumably the issue is that focus is on an element in a hidden (x-origin!) part of the frame tree when the keyboard shortcut is pressed, and either focus should have been moved automatically and/or we shouldn't be failing whatever checks are preventing events from bubbling up to the system/chrome parts just because (I'm guessing) we don't bubble events to the parent (x-origin) frame. Does that help? Happy to try and gather more info if you know what I should be looking for specifically (I tried setting some breakpoints in MSVC but couldn't really get anywhere, maybe in part because focus is also manipulated by switching away/back to windows...)

Oh, thanks! I'll try to create simple testcase.