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)
Tracking
()
VERIFIED
FIXED
M18
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.
Reporter | ||
Comment 1•24 years ago
|
||
nominating for beta3 and dogfood. i honestly see this just about every single time I file a new bug.
Comment 3•24 years ago
|
||
this is a critical bug. upping severity. It makes using bugzilla extremely unfriendly on Mac.
Severity: normal → critical
Comment 4•24 years ago
|
||
We are having a hard time reproducing it consistently. If anyone knows how please augment this bug.
Reporter | ||
Comment 5•24 years ago
|
||
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?
Comment 6•24 years ago
|
||
Don, kevin said I should assign this to you. If you need help call me.
Assignee: rods → dcone
Comment 7•24 years ago
|
||
Why do I get this, any other reason besides it says Mac OS?
Comment 8•24 years ago
|
||
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.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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.
Reporter | ||
Comment 11•24 years ago
|
||
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?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → M18
Assignee | ||
Comment 13•24 years ago
|
||
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.
Assignee | ||
Comment 14•24 years ago
|
||
*** Bug 53093 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
Comment 16•24 years ago
|
||
verified 2000092711 OS9
Updated•20 years ago
|
OS: Mac System 9.x
You need to log in
before you can comment on or make changes to this bug.
Description
•