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).
Yes, I get this with gnome+enlightenment as described. I spoke with pavlov and he knows where this was broken ... -> pavlov
Assignee: trudelle → pavlov
Status: UNCONFIRMED → NEW
Ever confirmed: true
nsbeta3+, p2 for M18
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → M18
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.
pdt agrees p2.
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
fixed on trunk only.. should this go in to the branch? I would think so.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
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 → ---
Assignee: pavlov → blizzard
Status: REOPENED → NEW
Trunk only for now, branch requires PDT approval, denoted by nsbeta3++.
*** Bug 24211 has been marked as a duplicate of this bug. ***
PDT marking nsbeta3-, but rtm++; please wait until after nsbeta3 to checkin to branch.
Whiteboard: [nsbeta3+][pdtp2] → [nsbeta3-][pdtp2][rtm++]
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.
*** Bug 54807 has been marked as a duplicate of this bug. ***
And did this patch get checked in? I don't see any new checkins with bug 52414 mentioned in their checkin title.
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.
Use pav's fix for now. It seems to work and fixing the bug the other way is not high on my list.
Okay. Pavlov, could you checkin your patch on the branch while this is still approved?
*** Bug 55942 has been marked as a duplicate of this bug. ***
reassigning back to self
Assignee: blizzard → pavlov
I'm going to resolve this fixed. We can open a different bug for the real problem here.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
verified fixed on trunk and branch linux builds.
Status: RESOLVED → VERIFIED
Keywords: relnote3, rtm
You need to log in before you can comment on or make changes to this bug.