Bug 1013744 - [e10s] Can't open Web Console using CMD+OPT+K and CMD+OPT+I keyboard shortcuts in e10s
https://bugzilla.mozilla.org/show_bug.cgi?id=1013744

Q: Where are the event handlers for those keyboard commands defined?

Interesting. So, it looks like other keyboard shortcuts work, like opening the Browser Console etc.

The command that opens up the Devtools Toolbox is Tools:DevToolbox...

And the handler calls gDevToolsBrowser.toggleToolboxCommand(gBrowser);

But we never hit that breakpoint, strangely.

Err... is that right? Actually, that's wrong - the keycombo that triggers Tools:DevToolbox is F12, and on OS X that switches displays to gadgets. Works on Windows, interestingly.

devToolboxMenuItem is what I'm interested in. Interestingly, this doesn't have a keycode attribute. Just uses label, accesskey, keytext.

I think Cmd-Shift-K is specifically for bringing up the console. Check out _createToolMenuElements which seems to be injecting these handlers.

attachKeyBindingsToBrowser seems to be doing it's job properly - it's injecting the <key> elements into the document. Also, it looks like the keyboard shortcuts work if the chrome is what's focused.

Q: How does key input work for remote browsers?

Things just get messaged down, and when they're done, I think the TabParent simulates the bubbling back up.

Q: Why do some <key>'s work with content (like DOMi), and some do not? (DevTools console)

So it looks like in nsXBLWindowKeyHandler::WalkHandlersAndExecute, we get the handler, but then have !aExecute, so the handler is never fired! Ignoring aExecute, things work properly.

Q: Why is aExecute false?

It looks like after we get the reply from the content process, and the key event is redispatched, the XBL key handler doesn't seem to pick it up. The only reason aExecute was false was because this was during the capturing phase.

Q: Why isn't the event getting handled after the TabChild replies?

It looks like the handler is registered and waiting, but the information we're getting back to compare it against isn't exactly right.

I think this is because the charCode isn't being sent to the TabChild, and then isn't being echo'd back.

Q: Why isn't the charCode being sent to the child?

I'm not sure, and now I'm not so sure that it even matters. Is the charCode set when the keyboard event _works_, like with Browser Console?

Q: Is the charCode set when the keyboard event _works_, like with Browser Console?

INTERESTING. It looks like the events work if the modifiers are accel, shift - but NOT accel, alt.

Let me see if this is true for non-devtools things. It's true!

Alt seems to be the red-headed step-child here. Or, at least, in certain combinations.

Ctrl+Alt S works
Ctrl+Shift+Alt S works
Ctrl-Accel S works
Alt-Accel S _does not work_.

Q: Why is alt not getting any love from nsXBLWindowKeyHandler?

AH HAH. So, first of all, this bug only affects OS X.

Also, on OS X, Alt+[key] usually results in alternative (ha!) character. Example - Alt+j = ∆. That character is what's serialized and sent back over the wire. So no wonder we're not handling it.

Q: How do <key>'s on OS X normally handle this?

nsContentUtils::GetAccelKeyCandidates seems to do the job here - basically, I think this takes some keyboard event, and returns candidate alternative key codes. This is failing with the events we get back from the child.

Q: Why is nsContentUtils::GetAccelKeyCandidates totally busted for the events that we get back from the child process?

I _think_ nsContentUtils::GetAccelKeyCandidates is not working because alternativeCharCodes on the WidgetKeyboardEvent isn't being properly serialized.

Hypothesis is correct! Got a patch up, but masayuki has suggestions.

evilpie wrote a variation on it, but still seems to think something is wrong.

Q: What is wrong with evilpie's patch?

"I first tried to get away with just serializing mozilla::AlternativeCharCode, but that doesn't work, because the serializer for for nsTArray needs an empty constructor."

Maybe it crashes? I'm going to try evilpie's patch to see if it actually works.

It works! It's just that evilpie couldn't test it - but it works really well.

evilpie is going to modify the patch to add a new type of serializer for AlternativeCharCodes which will clean things up again. Last round of review, and this puppy is DONE.