Mozilla ignores keyboard events unless mouse is inside window

VERIFIED FIXED in M18

Status

()

Core
XUL
P2
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Chris Siebenmann, Assigned: Stuart Parmenter)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

18 years ago
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

Comment 2

18 years ago
nsbeta3+, p2 for M18
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18

Comment 3

18 years ago
cc myself
(Assignee)

Comment 4

18 years ago
Created attachment 15054 [details] [diff] [review]
patch to fix regression
(Assignee)

Comment 5

18 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

Comment 6

18 years ago
pdt agrees p2.
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
(Assignee)

Comment 7

18 years ago
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 → ---
-> blizzard@mozilla.org
Assignee: pavlov → blizzard
Status: REOPENED → NEW

Comment 10

18 years ago
Trunk only for now, branch requires PDT approval, denoted by nsbeta3++.

Comment 11

18 years ago
*** Bug 24211 has been marked as a duplicate of this bug. ***

Comment 12

18 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

18 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

18 years ago
*** Bug 54807 has been marked as a duplicate of this bug. ***

Comment 15

18 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

18 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.
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

18 years ago
Okay.  Pavlov, could you checkin your patch on the branch while this is still
approved?  
(Assignee)

Comment 19

18 years ago
*** Bug 55942 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

18 years ago
reassigning back to self
Assignee: blizzard → pavlov
(Assignee)

Comment 21

18 years ago
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 ago18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
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.