Closed Bug 51649 Opened 25 years ago Closed 25 years ago

using comboxes w/out making a selection eats all keystrokes

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: danm.moz)

References

Details

(Keywords: platform-parity, Whiteboard: [dogfood+])

- go to a page with many comboboxes, such as the bug reporting page - drop down the platform combobox, but don't select anything from it a lot of the time (not 100%, but a most of the time) you won't be able to type in any form widget on the page until you click out of the app then back in. I wish i had a repro test case, but it happens enough of the time when I'm filing bugs that it should be noticeable by other testers (QA?) Seems to be mac only.
nominating for beta3 and dogfood. i honestly see this just about every single time I file a new bug.
Keywords: correctness, dogfood, nsbeta3, nsmac1, pp
Marking [dogfood+]
Whiteboard: [dogfood+]
this is a critical bug. upping severity. It makes using bugzilla extremely unfriendly on Mac.
Severity: normal → critical
We are having a hard time reproducing it consistently. If anyone knows how please augment this bug.
as I said to rod on the phone, it seems to appear more frequently when a page has recently been loaded (maybe a first time thing?) and goes away the longer you spend trying to reproduce it ;) as to the key eating complex, it smells like multiple key listeners are getting installed, but only one is removed, leaving a key listener hanging around chewing up keystrokes. does that help any?
Don, kevin said I should assign this to you. If you need help call me.
Assignee: rods → dcone
Why do I get this, any other reason besides it says Mac OS?
Having to click outside the app then back in sounds like a focus problem. If focus is incorrect the keystrokes will never get to the app.
Status: NEW → ASSIGNED
It seems that in nsMacMessagePump::DispatchOSEventToRaptor(), there is a check to see if the WindowPtr has a content region before continuing. Well on certain events (like these keydown events) the currently infocus widget is not the same as this window.. and these key down events don't get dispatched. If you take ou this check everthing works great .. except the rolled up windows will now get events.
Aha! This check for an empty window also causes bug 33735. It was put in there so that windowshaded windows don't accept keystrokes, but other apps don't behave this way. I'd be happy to have it taken out.
this "fix" also prevents tooltips from showing up on windowshaded windows. cc'ing danm. i've noticed, though, that listboxes also eat keystrokes when you use the scrollbar. different bug? same bug?
Giving to danm
Assignee: dcone → danm
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: --- → M18
We're now filtering only mousemove events for windowshaded windows. This bug is hard to reproduce, so I can't be certain, but it seems likely that this fixes the problem. I can't see it in my build now, anyway. Calling it fixed.
*** Bug 53093 has been marked as a duplicate of this bug. ***
Updating QA contact.
QA Contact: ckritzer → bsharma
Status: RESOLVED → VERIFIED
verified 2000092711 OS9
OS: Mac System 9.x
You need to log in before you can comment on or make changes to this bug.