Closed
Bug 52414
Opened 24 years ago
Closed 24 years ago
Mozilla ignores keyboard events unless mouse is inside window
Categories
(Core :: XUL, defect, P2)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: cks+mozilla, Assigned: pavlov)
References
Details
(Whiteboard: [nsbeta3-][pdtp2][rtm++])
Attachments
(1 file)
1.09 KB,
patch
|
Details | Diff | Splinter Review |
Build ID: current CVS pull/build Mozilla browser windows refuse to accept keyboard events (such as spacebar to scroll down) if the mouse is not over them (somewhere). This is a recent change and is highly annoying: the X focus policy is explicitly decoupled from where the mouse currently is for a good reason. Applications should accept keyboard/etc events if they have the focus regardless of where the mouse is. This is *not* the common 'must click in a window to push Mozilla into seeing it as focused' problem; this is a new, different, and highly annoying issue. Repeat by: - Set your window manager to have click to focus. - browse a page that requires scrolling. http://slashdot.org/ will do. - click on the browser window to focus it. - use spacebar to scroll. It will. - move the mouse pointer somewhere outside the window. Do not click it, leaving the Mozilla window focused still. - hit spacebar. Watch nothing happen. - move the mouse back in. - hit spacebar. Look, scrolling again. This is highly annoying, because people use focus policies besides 'focus follows mouse' precisely so they do *not* have to park their mouse pointer inside a window to use it. Mozilla is forcing them to do so, and silently making them think that something is broken until they notice the correlation. My environment: fvwm2, ClickToFocus and SloppyFocus focus policies (tested with both).
Comment 1•24 years ago
|
||
Yes, I get this with gnome+enlightenment as described. I spoke with pavlov and he knows where this was broken ... -> pavlov
Comment 2•24 years ago
|
||
nsbeta3+, p2 for M18
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Comment 3•24 years ago
|
||
cc myself
Assignee | ||
Comment 4•24 years ago
|
||
Assignee | ||
Comment 5•24 years ago
|
||
blizzard, please review this patch. I had added this code a while ago (I can find the revision if needed) and you made a change that removed the key listeners on mShell and added them only for mMozArea. This patch just adds them back to mShell so that keys get sent to the right place if your mouse is outside the window.
Keywords: patch
Assignee | ||
Comment 7•24 years ago
|
||
fixed on trunk only.. should this go in to the branch? I would think so.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 8•24 years ago
|
||
Wait, what the hell broke here? Someone broke something. Key events should always go to the mMozArea since whenever the shell gets focus, it automatically gives it to the mozarea and key events should work fine. Someone ( once again ) broke focus.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 10•24 years ago
|
||
Trunk only for now, branch requires PDT approval, denoted by nsbeta3++.
Comment 11•24 years ago
|
||
*** Bug 24211 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
PDT marking nsbeta3-, but rtm++; please wait until after nsbeta3 to checkin to branch.
Keywords: rtm
Whiteboard: [nsbeta3+][pdtp2] → [nsbeta3-][pdtp2][rtm++]
Comment 13•24 years ago
|
||
If we really aren't going to check this in for beta3, then we better release note this bug. :-( Personally, I think this will really make nsbeta3 suck for linux/unix.
Keywords: relnote3
Comment 14•24 years ago
|
||
*** Bug 54807 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
And did this patch get checked in? I don't see any new checkins with bug 52414 mentioned in their checkin title.
Comment 16•24 years ago
|
||
Chris, can update this bug with an ETA for landing a fix for this? Or is it OK to go with pavlov's original patch. Thanks.
Comment 17•24 years ago
|
||
Use pav's fix for now. It seems to work and fixing the bug the other way is not high on my list.
Comment 18•24 years ago
|
||
Okay. Pavlov, could you checkin your patch on the branch while this is still approved?
Assignee | ||
Comment 19•24 years ago
|
||
*** Bug 55942 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•24 years ago
|
||
I'm going to resolve this fixed. We can open a different bug for the real problem here.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 22•24 years ago
|
||
verified fixed on trunk and branch linux builds.
You need to log in
before you can comment on or make changes to this bug.
Description
•