Closed Bug 21610 Opened 25 years ago Closed 25 years ago

[DOGFOOD] overlays not loaded synchronously: need to click 4 times to get key events

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: hyatt)

References

Details

(Whiteboard: [PDT+] 12/17)

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.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Status: NEW → ASSIGNED
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.
Whiteboard: [PDT+] → Removed PDT+ read why
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
Whiteboard: Removed PDT+ read why → [PDT+]
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.
Whiteboard: [PDT+] → Removed [PDT+] read why
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.)
Blocks: 18033
This cannot be fixed quickly. A workaround would be to make platform-specific versions of the whole file (inputBindings.xul) and avoid using overlays.
Whiteboard: Removed [PDT+] read why → [PDT-]
We need this split up into several bugs. Putting on PDT- for this bug.
Assignee: saari → hyatt
Status: ASSIGNED → NEW
Summary: [DOGFOOD] Have to click 4 times to get key events → [DOGFOOD] overlays not loaded synchronously: need to click 4 times to get key events
Whiteboard: [PDT-]
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).
Status: NEW → ASSIGNED
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....
Whiteboard: [PDT+]
Putting on PDT+ radar.
Whiteboard: [PDT+] → [PDT+] 12/15 fix
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.)
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Priority: P3 → P2
Whiteboard: [PDT+] 12/15 fix → [PDT+] 12/17
Target Milestone: M12
targetting p2 for m12, changing fix date tentatively to 12/17
Target Milestone: M12 → M13
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Fixed.
Status: RESOLVED → VERIFIED
verified
You need to log in before you can comment on or make changes to this bug.