In order to get key events through to the urlbar, you have to - click in the urlbar (caret goes to the beginning, not where you clicked) - click in the content area outside the urlbar - click in the urlbar (caret goes to the beginning) - click in the urlbar (caret goes to where you clicked) This sequence has to be repeated every time you leave/reenter the browser window, since the urlbar loses focus on a leave event (bug 12051). This is impossible to discover (I'm seeing many bug reports that arrow keys don't work because users don't know about this focus problem) and several users have already nominated it for dogfood since you can't edit long urls or bugzilla queries if arrow keys don't work. Hyatt thought this had something to do with the lazy webshell in text fields, but I doubt it since it happens after leave/enter, not just on first focus.

Putting on PDT+ radar.

I just tried this on Windows with a build from last night and it worked. I launched, clicked once in the urlbar, and could use the arrow keys just fine. I'll try other OSes too, but people may want to check that this bug is still valid.

Hey, works on MacOS also. Same test build from last night.

Ok, I found one case where this happens, but it is not nearly as easy to do as it used to be. You have to click away from the urlbar into a title box on the sidebar. Everything else seems to work fine. I'd like a retest and a reconsideration of this bug as PDT+ since the difficulty of reproducing has gone up. In the mean time, I'll see what I can do

I just tried it on a Linux build updated this morning. I see several problems: - Clicking doesn't set the caret to the point where I clicked; I have to click again to do that. That's 21612. - On the first click, any key binding that uses the xul key (e.g. alt-C=Copy or alt-V=Paste on Unix) calls up a menu. On later clicks, this doesn't seem to happen, I get the correct copy or paste action. This is probably covered by existing menu accesskey bugs. - Nothing defined in the platform overlay gets through until I click several times. Hyatt said there might be a timing problem causing problems with overlay loading. I don't think there's a bug on that, so maybe we should make this bug cover that issue. Clicking twice doesn't do it, either: I have to click outside then again inside the widget (twice, to set the caret, so it's still the same four clicks as before) before I can usefully use platform overlay keys.

18033, which is PDT+ and has 22 votes, doesn't work right as long as this bug is in effect, since platform bindings are defined in an overlay. I'd like to see this stay PDT+ for that reason. (But I've put back saari's change to the whiteboard field; bugzilla set it back to just PDT+ when I added my last comment, I didn't do that intentionally.)

This cannot be fixed quickly. A workaround would be to make platform-specific versions of the whole file (inputBindings.xul) and avoid using overlays.

We need this split up into several bugs. Putting on PDT- for this bug.

This is a blocker for 18033. Hyatt now thinks that he can make this happen fairly easily, and told saari he'd take this bug. Requesting PDT reconsideration (and if you mark it PDT-, please explain how I can work around it for 18033).

I think I have a dup of this bug that has been marked PDT+. What the heck is going on here?

Shouldn't this be PDT+, since 18033 is depending on it, and it's PDT+?

David, you're implying that there is rhyme and reason behind the PDT+ designation....

Putting on PDT+ radar.

Ok, overlays will now load synchronously. Not that I'm even sure this was the original problem (I suspect the lazy webshell instantiation is causing even greater problems.)

This is actually worse now than it was yesterday. Not only does platformGlobalOverlay.xul not get loaded on the first click, but now neither does editorBindings.xul, so arrow keys no longer work on the first click.

Clearing FIXED resolution due to reopen.

targetting p2 for m12, changing fix date tentatively to 12/17

final m12 candidates are spinnning now. moving to m13. if we fall off track and need to respin m12 for some yet unknown reason we can consider this if you get a fix in hand.

We have an idea for how to work around the overlay problem. We'll modify the key listener to just check for platform versions of some bindings and look there first. 12/17 looks promisingly likely.

Fixed.

verified