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
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
Ugh. Is this a regression? Can someone check this with an older build, like a few weeks, and see if this problem exists?
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.
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
* sigh * really cc:ing bryner. Brian, can please read my last comment and let me know if you have any ideas? Thanks
Summary: Drop down menus disappear when focus follows mouse pointer → <SELECT>s disappear when using X-Mouse
*** 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?
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.
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
bryner, can you take a look at the two patches sometime, to make sure I didn't miss any occurrences of ShouldRollupOnMouseWheelEvent?
-->mozilla0.9.5, since I have a patch that's ready to be looked at
Target Milestone: mozilla1.0 → mozilla0.9.5
bryner, can you r= this, since I'm basically mimicking your code that I was using in the first place?
Is this patch going anywhere? I'd really like to see this land.
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Ping. Looking for r=/sr=.
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+
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.
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. :)
I think timeless's review still stands. Can I get an sr=, please?
This didn't make 0.9.6. Anyone care to sr?
Target Milestone: mozilla0.9.6 → mozilla0.9.7
*** Bug 111580 has been marked as a duplicate of this bug. ***
* sigh *
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 on attachment 57408 [details] [diff] [review] cvs diff -u of the widget directory sr=hewitt (for both patches)
Attachment #57408 - Flags: superreview+
Comment on attachment 57408 [details] [diff] [review] cvs diff -u of the widget directory reviews for both patches still apply
Attachment #57408 - Flags: review+
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified fixed on NT4.0 & W2K Pro
Status: RESOLVED → VERIFIED
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.