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.