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)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cks+mozilla, Assigned: pavlov)

References

Details

(Whiteboard: [nsbeta3-][pdtp2][rtm++])

Attachments

(1 file)

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
Keywords: nsbeta3
nsbeta3+, p2 for M18
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
cc myself
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
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
Closed: 24 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 → ---
-> blizzard@mozilla.org
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.
Keywords: rtm
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.
Keywords: relnote3
*** 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
Closed: 24 years ago24 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.

Attachment

General

Created:
Updated:
Size: