<SELECT>s disappear when using X-Mouse

VERIFIED FIXED in mozilla0.9.7

Status

()

Core
XUL
--
minor
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: TGOS, Assigned: Dean Tessman)

Tracking

Trunk
mozilla0.9.7
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

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

17 years ago
I can't find the original bug right now, but I'm pretty sure this is a dupe.
giving this to dean, who i think did the work last time.
Assignee: pinkerton → dean_tessman
(Assignee)

Comment 3

17 years ago
Ugh.  Is this a regression?  Can someone check this with an older build, like a 
few weeks, and see if this problem exists?
(Reporter)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
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?

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 6

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

Updated

17 years ago
Summary: Drop down menus disappear when focus follows mouse pointer → <SELECT>s disappear when using X-Mouse
(Assignee)

Comment 7

17 years ago
*** Bug 87967 has been marked as a duplicate of this bug. ***
Perhaps a stupid question, but why are we calling
ShouldRollupOnMouseWheelEvents() if you're not using the mouse wheel?
(Assignee)

Comment 9

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

(Assignee)

Comment 10

17 years ago
Created attachment 43196 [details] [diff] [review]
cvs diff -u of widget directory
(Assignee)

Comment 11

17 years ago
Created attachment 43197 [details] [diff] [review]
cvs diff -u of layout directory
(Assignee)

Comment 12

17 years ago
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.
Keywords: patch, review
(Assignee)

Comment 13

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

Comment 14

16 years ago
-->mozilla0.9.5, since I have a patch that's ready to be looked at
Target Milestone: mozilla1.0 → mozilla0.9.5
(Assignee)

Comment 15

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

Comment 16

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

Comment 17

16 years ago
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Comment 18

16 years ago
Ping.  Looking for r=/sr=.

Comment 19

16 years ago
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)
Attachment #43196 - Flags: needs-work+
(Assignee)

Updated

16 years ago
Attachment #43196 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #43197 - Attachment is obsolete: true
(Assignee)

Comment 20

16 years ago
Created attachment 57407 [details] [diff] [review]
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.
(Assignee)

Comment 21

16 years ago
Created attachment 57408 [details] [diff] [review]
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. :)
(Assignee)

Comment 22

16 years ago
I think timeless's review still stands.  Can I get an sr=, please?
(Assignee)

Comment 23

16 years ago
This didn't make 0.9.6.  Anyone care to sr?
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 24

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

Comment 25

16 years ago
* sigh *
(Assignee)

Comment 26

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

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

sr=hewitt (for both patches)
Attachment #57408 - Flags: superreview+

Comment 28

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

reviews for both patches still apply
Attachment #57408 - Flags: review+
(Assignee)

Comment 29

16 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 30

16 years ago
Verified fixed on NT4.0 & W2K Pro
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.