6582 - [FOCUS/ACT] Background windows should not respond to mouseovers (:hover)

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Simon Fraser [no longer active]]

Mousing over buttons in a non-foreground window shows the normal 'location
hilight' mouserover effect. Since the first click in a background window
simply brings the window to the front, the buttons in a background window
should not show mouseover hillight.

Comment 1

[Peter Trudelle]

reassigning to evaughan as p4 for m15

Comment 2

[Simon Fraser [no longer active]]

This is a regression from 4.5, so I'd like to see it get slightly higher priority
than M15.Also note that controls (scroll bars etc) in background windows should
also be disabled.

Comment 3

[Eric Vaughan]

Tom,

This seems to be an event thing. Windows that are not in focus should net be
sending mouse moves to their children.

Comment 4

[joki (gone)]

I'm not sure what the right behavior is here.  As far as the content area goes,
in Windows 4.5 mousing over links, imagemaps, etc, does work in background
windows.  Mousing over the UI gives random results (ie the bookmark dragspot
changes but the buttons don't hilight).  I know that Mac behavior for
non-foreground windows has always been different that Windows behavior, more
use of disabling and such.  But on Windows, at least, its not as simple as not
passing event to background windows since that it correct behavior.  The
background window can choose not to do anything but it should get the events.

Comment 5

[Mike Pinkerton (not reading bugmail)]

*** Bug 7956 has been marked as a duplicate of this bug. ***

Comment 6

[Simon Fraser [no longer active]]

*** Bug 7402 has been marked as a duplicate of this bug. ***

Comment 7

[Simon Fraser [no longer active]]

I adjusted the summary to reflect the following:
1. This bug concerns both setting the cursor (from bug 7956), and doing button
   mouseover.
2. Neither of these things should happen in
   i) background windows.
   ii) any window, if the app is not frontmost (Mac)

Setting the cursor when you are not the frontmost app is a serious usability
problem on Mac. Adjusting priority to reflect this.

Comment 8

[Matthew Thomas, usability weenie]

Official reference for this Mac UI design rule:
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-114.html

-- mpt

Comment 9

[Paul MacQuiddy]

giving me rest of phillips open qa contact bugs, sorry for spam

Comment 10

[Paul MacQuiddy]

*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to
[e-mail]

Comment 11

[Paul MacQuiddy]

*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
[e-mail]

Comment 12

[joki (gone)]

Mass-moving bugs out of M15 that I won't get to.  Will refit individual 
milestones after moving them.

Comment 13

[joki (gone)]

Bulk prioritizing bugs for correct milestones.

Comment 14

[joki (gone)]

Adding focus/activation prefix for tracking.

Comment 15

[ckritzer (gone)]

->saari

Comment 16

[Peter Trudelle]

->future

Comment 17

[saari (gone)]

Would be nice to fix. Mozilla 1.0

Comment 18

[saari (gone)]

Would be nice to fix. Mozilla 1.0

Comment 19

[Marcia Knous [:marcia]]

nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 

Comment 20

[saari (gone)]

sorry, this won't stop people from using the product

Comment 21

[Matthew T (active 1999-2002)]

This applies to mouseovers in Web pages, too, not just those in the chrome -- 
so it can't be achieved just by disabling all the chrome widgets. Making chrome 
widgets in background windows look disabled, as Simon mentioned in his
1999-05-25 comment, is covered by bug 54488.

Comment 22

[Greg K.]

See also bug 193088.

Comment 23

[Mark Mentovai]

Fixed in bug 340592