86606 - <SELECT>s disappear when using X-Mouse

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[TGOS]

I'm currently using  BUILD ID: 2001061708

In Windows you can enable an option named:
"Activation follows mouse (X-Mouse)" (in Tweak-UI)
That causes your mouse pointer to act like an X-Window
mouse pointer, meaning the focus follows your mouse
pointer (always the window below my mouse pointer is
active, but it isn't raised, just active).

I always use this option, because I'm used to such a
behavior from Linux. When I open a pull down element
in forms (like the one on the current page where I can
choose my OS for example) and try to move my mouse
pointer onto the this kind of menu, it will immediately
dissaper before I had any chance to choose something.

If I switch back to standard mouse behavior in Windows
(where only clicking changes the active window), the pull
down elements work like they should.

The only way to change something from those pull down menus,
is by keeping the mouse button pressed after I clicked the
pull down element and then move it over this menu. Now the
menu won't dissapear and I can choose something by releasing
the mouse button over a specific item.

The problem: If the menu is very long, I won't be able to make
use of the scroll bars, so I have to scroll through the menu
element by element. I can't release the mouse button without
choosing an element and if I don't keep the mouse button pressed,
I won't even be able to get onto the menu.

Summary:
--------

Actual beavhior: The menu dissapers whenever I move the mouse pointer
over it and my mouse button isn't pressed

Expected behavior: The menu will stay there as long as I haven't
chosen any element from the list

Comment 1

[Warner Young]

I can't find the original bug right now, but I'm pretty sure this is a dupe.

Comment 2

[Mike Pinkerton (not reading bugmail)]

giving this to dean, who i think did the work last time.

Comment 3

[:deanis74]

Ugh.  Is this a regression?  Can someone check this with an older build, like a 
few weeks, and see if this problem exists?

Comment 4

[TGOS]

This bug duplicates bug 16037, but 16037 was marked as fixed. To quote from
16037: "This is fixed for me as of 0.8.1, on both 98 and NT."
In 0.9.1 it's somehow back.

Comment 5

[:deanis74]

Well, bug 16037 isn't exactly back.  Menus still work as expected.  It's just 
<select>s that are broken within HTML pages.  I downloaded mozilla0.8.1 and this 
bug is there as well.

Reporter, there's a work-around mentioned in bug 16037 that works.  Set the 
activation delay to anything non-zero, even 1 ms.

Accepting and targetting.  Now why the heck would <select>s behave differently?  
Oh waitasec... My fix for bug 50798 checks ShouldRollupOnMouseWheelEvents().  In 
some quick testing, this is false for <select>s.

CC: bryner -- any ideas?

Comment 6

[:deanis74]

* sigh *  really cc:ing bryner.  Brian, can please read my last comment and let 
me know if you have any ideas?  Thanks

Comment 7

[:deanis74]

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

Comment 8

[Brian Ryner (not reading)]

Perhaps a stupid question, but why are we calling
ShouldRollupOnMouseWheelEvents() if you're not using the mouse wheel?

Comment 9

[:deanis74]

I'm having trouble remembering, but looking back at some comments you left in
bug 50798... "Yeah, ShouldRollupOnMousewheelEvent will give the right results, I
think.  The only thing I don't like is the naming, since this isn't a mousewheel
event... perhaps we should rethink this API at some point."

Sounds like this may be the time to clone this into a second api.

Comment 10

[:deanis74]

Attachment: cvs diff -u of widget directory

Comment 11

[:deanis74]

Attachment: cvs diff -u of layout directory

Comment 12

[:deanis74]

These two patches move the x-mouse activation check into its own API, instead of
relying on ShouldRollupOnMouseWheelEvent.  Fairly straight-forward, and fixes
the <select> problem.

Comment 13

[:deanis74]

bryner, can you take a look at the two patches sometime, to make sure I didn't 
miss any occurrences of ShouldRollupOnMouseWheelEvent?

Comment 14

[:deanis74]

-->mozilla0.9.5, since I have a patch that's ready to be looked at

Comment 15

[:deanis74]

bryner, can you r= this, since I'm basically mimicking your code that I was
using in the first place?

Comment 16

[Corey Puffalt]

Is this patch going anywhere?  I'd really like to see this land.

Comment 17

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 18

[:deanis74]

Ping.  Looking for r=/sr=.

Comment 19

[timeless]

Comment on attachment 43196 [details] [diff] [review]
cvs diff -u of widget directory

>Index: public/nsIRollupListener.idl
>@@ -41,4 +41,9 @@
>+   * Asks the RoolupListener if it should rollup on mouse activate, eg. X-Mouse
even typos in comments are unacceptable :(
>+  void ShouldRollupOnMouseActivate(out PRBool aShould);

everything else is ok (r=timeless)

Comment 20

[:deanis74]

Attachment: cvs diff -u of the layout directory

New diff of layout.  This is up-to-date with the current trunk, and also fixes
up a mess-up in the license block, Original Author was below Contributors.

Comment 21

[:deanis74]

Attachment: cvs diff -u of the widget directory

Up-to-date with latest revision on the trunk, fixes spelling mistake, and fixes
spelling mistake in the text I copied it from. :)

Comment 22

[:deanis74]

I think timeless's review still stands.  Can I get an sr=, please?

Comment 23

[:deanis74]

This didn't make 0.9.6.  Anyone care to sr?

Comment 24

[R.K.Aa.]

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

Comment 25

[:deanis74]

* sigh *

Comment 26

[:deanis74]

I think Hewitt needs this to fix his titletip-eats-clicks problem on Windows.  I
would like to get this in for 0.9.7, can I get r=/sr=, please?

Comment 27

[Joe Hewitt (gone)]

Comment on attachment 57408 [details] [diff] [review]
cvs diff -u of the widget directory

sr=hewitt (for both patches)

Comment 28

[timeless]

Comment on attachment 57408 [details] [diff] [review]
cvs diff -u of the widget directory

reviews for both patches still apply

Comment 29

[:deanis74]

checked in

Comment 30

[Corey Puffalt]

Verified fixed on NT4.0 & W2K Pro