Closed Bug 51649 Opened 24 years ago Closed 24 years ago

using comboxes w/out making a selection eats all keystrokes

Categories

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

PowerPC
Mac System 9.x
defect

Tracking

()

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. 
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: 24 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.