Closed Bug 102578 Opened 24 years ago Closed 22 years ago

Clicking wrongfully fires onmouseout (dhtml menus, css/edge menus)

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: simon, Assigned: bryner)

References

(
URL
)

Details

(Keywords: platform-parity)

Attachments

(5 files, 4 obsolete files)

Always better to add testcase to bugzilla
986 bytes, text/html
Details
patch
4.08 KB, patch
Details | Diff | Splinter Review
More specific Xlib patch
3.04 KB, patch
blizzard
: review+
bryner
: superreview+
Details | Diff | Splinter Review
patch with style cleanup
1.98 KB, patch
Details | Diff | Splinter Review
Reworked gtk patch
2.45 KB, patch
blizzard
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Clicking a DIV element causes its onMouseOut event handler to be run. I tried the test case (see URL) in the following Mozilla's: Linux/Mozilla 0.9.4 - EXHIBITS PROBLEM W2K/Mozilla 0.9.3 - DOES *NOT* EXHIBIT PROBLEM Others (on #mozilla) have tried the test case in the followind Mozilla's: Linux/Very Recent CVS Build - EXHIBITS PROBLEM W2K/Mozilla Recent CVS Build - DOES *NOT* EXHIBIT PROBLEM Hence the conclusion that this bug is Linux platform specific.
wfm 2001100108 linux from cvs with --disable-xprint --disable-tests --disable-bidi --disable-ldap --disable-accessibility --enable-crypto --disable-debug --enable-optimize="-O2 -mcpu=k6 -march=k6" --enable-strip-libs --with-extensions=default,irc and modern theme on KDE 2.2.1 with glibc and X from slackware 8.0
I am confirming this bug on Linux RedHat 7.1, Ximian Gnome, with mozilla build 2001100906. The test-case square does turn white when I click in it.
Marking WORKSFROME Reporter, Try a newer a newer build, please reopen if you see it again...
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Oops my Mistake, Confirming per Sebastian's Comment and Marking this Confirmed Changing to NEW
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm taking so I can try to verify it, but it sounds like it might be something for blizzard or bryner
Assignee: joki → saari
Wow, that's wierd.
blizzard, bryner, I don't even have a linux box at this point, can either of you take this?
Keywords: pp
-> bryner
Assignee: saari → bryner
*** Bug 107083 has been marked as a duplicate of this bug. ***
*** Bug 124575 has been marked as a duplicate of this bug. ***
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=68710 from bug 124575 the click seems to make a drag-event stick to it? I see the drag paper-cursor when moving out of the image after a click, and have to dismiss the dialog with two clicks, not one as expected. The first click only unsets the drag.
-> 1.0, nominating for beta1.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
nsbeta1- per ADT triage team
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
QA Contact: madhur → rakeshmishra
Also possibly of note: holding down Ctrl while clicking does not fire the onMouseOut event. This holds true regardless of whether the Tabbed Browsing hook for Ctrl-Click is set.
QA Contact: rakeshmishra → trix
Boy, this is really a bad bug for menu systems. Any menu system that uses a click to open now fails. This really sux if you are attempting to emulate a desktop drop-down menu system. Since so many sites use this, this is really a bad situation.
I just noticed after some testing that this only happens the first time you click on an element. After that it behaves as expected.
See also bug 132592, which is specifically about this issue in connection with javascript menus. This bug has a couple of testcases and about eight duplicates. See also bug 113492, the dynamic menu tracking bug.
*** Bug 189287 has been marked as a duplicate of this bug. ***
*** Bug 132592 has been marked as a duplicate of this bug. ***
*** Bug 132968 has been marked as a duplicate of this bug. ***
Does anyone still see this? I dont have any problems on build 2003-01-13-08-trunk on Linux RedHat.
Just downloaded latest nightly build 2003011922 and the bug is still present!! (System: SuSE Linux 8.1) My own testpage for this bug is: http://www.ahicre.de/moztest/linktest.html The links in the javascript displayed/hidden menu don't work because of this bug. I would like to have this bug a higher priority/severity, it is really a serious bug because it makes navigating impossible on many sites that use dynamic menus! The bug is over one year old now and there were 6 dups. It's time to get it fixed!
there are 14 dupes. bug Bug 132592 itself had 8.
*** Bug 190010 has been marked as a duplicate of this bug. ***
*** Bug 190428 has been marked as a duplicate of this bug. ***
This still doesnt work properly...I have tried Mozilla 1.3a( from mozilla.org), Mozilla 1.2.1( from mozilla.org), and Mozilla 1.0.1 (latest Redhat update rpm). Menus do not work properly at http://www.bribieisland.net I am running Redhat Linux 7.3 Each Mozilla mentioned above exhibits the problem of not being able to select a menu item, click on it and have it work correctly. However, all three releases will succesfully activate the menu items if they are Control-Clicked, instead of just clicked. Also the menu items can by activated by mousing over a menu item, moving mouse to submenu item, click submenu item and hold button down for a while. Whilst still holding butom down, move mouse a couple of pixels. menu item is highlighted again, release mouse button, menu item is fired. Other posts indicate that this works properly in some cases. But none of the releases above work properly on my system. Could this have something to do with the X server, or is it still a linux specific bug?
*** Bug 190594 has been marked as a duplicate of this bug. ***
further to post #27 Changing window manager from gnome1.4/sawfish to fvwm and icewm allows mozilla to behave correctly. This clearly is something to do with gnome/sawfish window manager.
Brad: this does have weird windowmanager-type behavior, but I think some people using Gnome/sawfish don't see it. And I see it with blackboxwm.
Blocks: 113492
I've run into this myself and it's a configuration issue with sawfish. If you have button 1 set to "raise transients" then this problem will show up. I'm not sure how to filter out the incorrect mouseout event.
I see this bug on all SuSE systems I have been using for the last year (7.3, 8.0, 8.1) using the KDE desktop and KDE window manager, so this bug can not have something to to with GNOME/Sawfish only.
Blocks: 192065
I hooked gdb up to handle_gdk_event() in widget/src/gtk/nsGtkEventHandler.cpp and tried a few tests using the attached testcase. Under KDE 3.0, clicking on the box generates about six GDK_LEAVE_NOTIFY events, followed by six GDK_ENTER_NOTIFY events, followed by the button press & release events. The box appears to turn white simultaneously with the button press. Ctrl-click and shift-click appear to work the same as plain click. Alt-click generates the leave & enter events without the button press events; this also causes the box to turn white. Hitting alt-tab causes kde to display a bar containing all of the applications in the workspace, which the user can cycle through. Simultaneously mozilla receives six leave events and the box turns white. When I tab back around to mozilla and release the alt key, mozilla receives six enter events but the box stays white. Behavior under gnome 2.0, using the metacity window manager, was identical to kde, except that ctrl-click and shift-click only generate button press & release without any leave or enter events; the box doesn't turn white in these cases. Finally I started mozilla under Xnest and hooked gdb up to that copy: xinit ./mozilla --display :2 -- $(which Xnest) -auth $HOME/Xauth :2 Here, when I click on the box, mozilla receives three events: mouse motion, button press, and button release. Mozilla works as expected; the background flashes blue but the box stays black. In short, these GDK_LEAVE_NOTIFY events are apparently triggering the onmouseout handler. Apparently mozilla isn't smart enough to ignore a leave event followed by an enter event. It also isn't triggering onmouseover in response to GDK_ENTER_EVENT--I think there are other bugs about this.
Using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 Url:http://www.trendmicro.com/en/products/global/enterprise.htm Continues to not work.
This may be a dumb question, but is this related to bug 103055?
cc'ing jkeiser for his opinion on that. Note, though, bug 103055 was filed under Windows, whereas the current bug seems to be Linux-only (?)
There was a fix checked in for bug 103055 yesterday. Does this now work on builds of February 15 or later?
still exists with CVS today, so the two are unrelated.
Some additional test results produced under linux/KDE mandrake 9, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826, Galeon 1.2.3, both using microsoft mouse emulating 3 buttons:- Button down on a blank part of the DIV fires mouseout on the DIV before mousedown. If over a text element, mouseout is not fired and you can select text. The mouseout event registers the mouse out of the window (event.relatedTarget = null), so moving the mouse immediately after mouse down will compare positions and refire mouseover of the DIV. The workaround in event handlers is to use the fact that mousedown implies mouseover and reprocess mouseover as needed. Re comment 35, this bug defeats workarounds for (ex?) bug 103055 which checked event.relatedTarget for lineage.
*** Bug 193833 has been marked as a duplicate of this bug. ***
*** Bug 194597 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a?
*** Bug 195922 has been marked as a duplicate of this bug. ***
I reported the bug 195922 which has been assigned beeing a duplicate of this bug here - this bug here seems to be always present - the behaviour I reported does NOT always happen. It just exists from one random (?) moment on an persists until restarting the window manager. So why can onclick force mouseout at one time and not at another ?
Georg: others have experienced the same "sporadic" nature of the bug. For example, see the duplicate bug 132968. The reporter of that one found the bug would go away if he restarted his X session. Also note comment 27 and following in the current bug -
This isn't really linux-specific. I've reproduced it on solaris and I'm about to dupe a freebsd bug to this. If anything it's probably X-specific or gtk-specific.
Summary: clicking wrongfully fires onmouseout (linux specific bug) → Clicking wrongfully fires onmouseout
*** Bug 144377 has been marked as a duplicate of this bug. ***
still exists in mozilla 1.3 release
*** Bug 198343 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a? → blocking1.4a-
Bug 195922 has been marked as a duplicate of this bug. The url mentioned in that bug is ..... http://www.meyerweb.com/eric/css/edge/menus/demo.html see Bug 195922 comment 0 for description.
Another site that is (I think) hurt by this is http://www.actebis.cz/ Is there any known workaround? This is very annoying...
*** Bug 202466 has been marked as a duplicate of this bug. ***
Blocks: 183502
We're way past the 1.2alpha milestone. Can we get this retargetted?
No longer blocks: 183502
*** Bug 183502 has been marked as a duplicate of this bug. ***
I think it can help: the menu in my site is activated by clicking on an image. I can reproduce the bug on my Gnome on Red Hat 7.3 and 8 but there is a sequence that always works. If you press your mouse button, move it and then release the button (onmousedown, onmousemove, onmouseup) onmouseclick is fired and onmouseout is correctly not fired.
*** Bug 204436 has been marked as a duplicate of this bug. ***
*** Bug 205866 has been marked as a duplicate of this bug. ***
*** Bug 206011 has been marked as a duplicate of this bug. ***
I think this bug is X Server or GTK specific. It went away after I restarted X and then came back again. This bug effectively disables dhtml drop down menus on a significant bunch of test sites I visited.
re: bug #205866: (I filed, marked as duplicate of this one) updating the system in question to redhat 9, recompiling the mozilla 1.4b src rpm and installing it did allow www.aqua.org to work. However, there are still problems with my online banking, whihc may be the same problems I was experiencing trying to order tickets over moviefone.com. Many links might have a picture icon, but the first N mouse clicks are ignored (for example, on moviefone, try to purchase a ticket, and select a time for a show)
As I said on #138452 on this comment http://bugzilla.mozilla.org/show_bug.cgi?id=138452#c35 On Debian I correct the bug reinstalling libstdc++2.9-glibc2.1, If I install 2.10 version of this library the bug appears
*** Bug 211381 has been marked as a duplicate of this bug. ***
hallelujah this appears to now work fine in 1.4 final, at least with my own problem websites and the websites mentioned throughout the life of this bug. suggest closing?
My Galeon CVS compiled against 1.5a still exhibits the problem with the attached testcase.
mozilla 1.4, recompiled for rh9 from the rh8 srpms in the /contrib directory. Two of the cases, http://www.aqua.org and http://www.moviefone.com now work. My bank's account manager does nothing on some of the javascript based menus. I do not know if they're related.
I still have the problem behavior at site http://www.voyence.com/ using Mozilla 1.4.
I'm definitely still seeing the problem at http://www.actebis.cz/ with Mozilla 1.4rc3 on Linux.
ok as it seems to work for me, here's my buildconfig: Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.3 (Mandrake Linux 9.2 3.3-2mdk) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pthread -pipe c++ gcc version 3.3 (Mandrake Linux 9.2 3.3-2mdk) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug --disable-pedantic --enable-strip --disable-tests --enable-crypto --enable-nspr-autoconf --with-default-mozilla-five-home=/usr/lib/mozilla-1.4 --enable-extensions --disable-short-wchar --enable-xinerama --enable-mathml --without-system-nspr --with-system-zlib --enable-ipv6 --enable-old-abi-compat-wrappers --mandir=/usr/share/man --enable-xft --disable-freetype2 --enable-default-toolkit=gtk2
*** Bug 212013 has been marked as a duplicate of this bug. ***
*** Bug 212291 has been marked as a duplicate of this bug. ***
*** Bug 212359 has been marked as a duplicate of this bug. ***
Summary: Clicking wrongfully fires onmouseout → Clicking wrongfully fires onmouseout (dhtml menus, css/edge menus)
I tried the click down drap realse and that worked for http://www.bribieisland.net but didn't for http://tinyurl.com/h3wa On the LinuxExpo site the menu disappears as soon as I click on it. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428
*** Bug 212857 has been marked as a duplicate of this bug. ***
WM: Openbox 2.3.1 OS: Debian unstable MOZ: 1.0.2, 1.2.1, 1.3.1, 1.4 (FB 0.6) With "Click Raise" enabled in openbox (raising the window no matter where the click occurs), I see the problem. Disabled, every site worked, including bestbuy.com (my dupe of this bug). Some of the sites in this bug don't have DHTML menus that I can see, maybe that's how they were some time ago. Unfortunately I like this click raise behavior. :P So... What is the source of all these problems? 1) specific window managers (with click to focus enabled) 2) libstdc++ (haven't tried to downgrade) 3) maybe some combination of the above or something else completely I'm really not familiar with openbox source, but it might be possible (?) to add a timer for the click to raise functionality, say 250ms, so that mozilla can still catch the click event and not trigger onmouseout right away. Openbox is still pretty similar to Blackbox (and Fluxbox), so I'd imagine this kindof patch could probably apply to all.
The problem is certainly not specific to openbox, as I see it with KDE 3.0.x. However, it is true that I have click-to-raise (if that's what it's called) enabled (as is the default, I think).
Fluxbox 0.9.4, with or without click anywhere to raise has this problem. Opera 7.11 won't even display the menu I've tried (??). However, the attached testcase does seem to work as it should.
*** Bug 213112 has been marked as a duplicate of this bug. ***
*** Bug 205461 has been marked as a duplicate of this bug. ***
This bug really irritated me today, so I took a look into it. It appears that mozilla is mistaking mouse grab notifications as real enter/leave events. Window managers such as sawfish and metacity grab the mouse so that they can decide whether a click event needs to be handled by them. This happens, for example, to check for window move or resize commands. When a client gets the mouse grabbed from it, it will receive a LeaveNotify event followed by an EnterNotify event with the mode set to NotifyGrab or NotifyUngrab (at least that what I could figure from the xlib docs and metacity source code). At any rate, real Enter/Leave events have a mode of NotifyNormal. I'm attaching a patch which fixes this issue for gtk widgets. I believe that the xlib and gtk2 widget implementations have the exact same problem, but I don't have any time to rebuild moz with new options.
This patch makes mozilla's gtk windows ignore Enter/Leave events which indicate mouse grabs. This is against MOZILLA_1_4_RELEASE.
Attachment #128390 - Flags: review?(bryner)
*** Bug 174204 has been marked as a duplicate of this bug. ***
Here's a similar patch for gtk2. I've tested this on KDE; all of the web pages mentioned in this bug work fine, and no problems have been noted.
*** Bug 213798 has been marked as a duplicate of this bug. ***
*** Bug 210979 has been marked as a duplicate of this bug. ***
Comment on attachment 128390 [details] [diff] [review] Patch to ignore Enter/Leave events which indicate mouse grabs. r=bryner, nice find.
Attachment #128390 - Flags: review?(bryner) → review+
Attachment #128424 - Flags: review+
Comment on attachment 128390 [details] [diff] [review] Patch to ignore Enter/Leave events which indicate mouse grabs. The gtk1 patch works - haven't tried the gtk2 one.
Attachment #128390 - Flags: superreview?(blizzard)
Attachment #128424 - Flags: superreview?(blizzard)
Comment on attachment 128424 [details] [diff] [review] GTK2 patch to ignore pointer-grab events This actually breaks some legitimate events. For example, if I press alt-space to bring up the window manager menu in metacity the mouse out, which is legit, is dropped.
Attachment #128424 - Flags: superreview?(blizzard) → superreview-
Attachment #128390 - Flags: superreview?(blizzard) → superreview-
I guess I'll have to break down and craft up a work-around. Sigh.
Attached patch patch — — Splinter Review
This patch tries to find a corresponding enter event for any leave event with a timeout of 10 milliseconds. If it finds one, it drops both events.
Attachment #128390 - Attachment is obsolete: true
Attachment #128424 - Attachment is obsolete: true
Mental note: it occurs to me that we can optimize this by running this only when there's a leave w/ a non-normal status.
I'd like to comment on Comment #86 From Christopher Blizzard. I'm not sure that I agree with your assessment of the Metacity window manager menu example for two reasons. First, the Grab/Ungrab events are not meant to represent legitimate Enter/Leave conditions. In this example, the mouse does not leave the element it was over, and so it seems unexpected that it would receive a mouseout event without some other cause. Second, in cases where the window-manager pops up another UI element such as this menu, the window receives an Unfocus event. Therefore, Unfocus would seem to be a more appropriate cause for generating a mouseout event than the amount of time between Grab and Ungrab. For a good example of wrong behavior with the timeout heuristic, do this: * Run xev under metacity. * Hold down the ALT key and left mouse button like you were going to move the window. * Release the mouse button. You've just wrongly triggered the timeout. The same scenario can also occur due to heavy system loads/thrashing. On another note, the complexity introduced by event counting seems a bit heavy- weight for a behavior that most users will never remark and for which those who do will not be adversely affected by it. Was this just a bad example? Is there a better example which exhibits unexpected behavior or detrimental behavior?
blizzard: why are you expecting a mouseout when you bring up the window manager menu?
Attached patch More specific GTK2 patch (obsolete) — — Splinter Review
For the record I tend to agree with comment #90, but here is a new patch for gtk2 that addresses blizzard's objection. Under metacity at least, the pointer is grabbed for the window representing the window manager frame, which is an ancestor of the mozilla windows that it contains. So, when the mouse is clicked, the events received by mozilla are tagged NotifyAncestor or NotifyVirtual. Events from menu popups and pointer grabs by other clients involve a window outside of the mozilla objects' direct line of ancestry, so they're tagged NotifyNonlinear or NotifyNonlinearVirtual. This patch causes mozilla to ignore only the first class of events.
For the sake of simplicity, I'd rather not use the patch that I wrote up here. And grabs do cause mouseout so I'd rather not try to fake that using focus events just because we ignore the mouseout events from grabs. I need to do a little reading and thinking when I get home.
Herron: You have me convinced that your latest patch is the way to go. It's clear, and it works. Nice job!
*** Bug 214477 has been marked as a duplicate of this bug. ***
Attached patch More specific GTK patch (obsolete) — — Splinter Review
GTK version of Kenneth Herron's patch.
lib version of Kenneth Herron's patch.
*** Bug 215048 has been marked as a duplicate of this bug. ***
For the record, I've been using patch #128857 (the second GTK2 patch) on KDE 3/linux and Gnome 2/Solaris ever since submitting it, and I've had absolutely no problems.
*** Bug 218790 has been marked as a duplicate of this bug. ***
Just to add another example of the bug on a element with an :hover:after style : http://n.mo.free.fr/bug/css/hoverafter.htm
blizzard mentioned on irc that he has something in his tree which he needs to commit and that Fedora 1 has a fixed metacity WM which won't exhibit this bug
Final patch for gtk2, just fixed up some style nits.
Attachment #128857 - Attachment is obsolete: true
Checked into the gtk2 code.
Could we drive in the GTK and xlib patches too, please?
Blocks: 221957
Attachment #128910 - Flags: review?(blizzard)
Comment on attachment 128909 [details] [diff] [review] More specific GTK patch Chris, could you please review this?
Attachment #128909 - Flags: review?(blizzard)
Spammers are now harvesting e-mail addresses from this page. Is there anything that can be done?
>Is there anything that can be done? Yes, hide email addresses unless logged in, there was a bug somewhere about that don't know where it went.
Are you saying that there is a bug in bugzilla that is allowing e-mail addresses to be harvested so that I can be told I can have a bigger penis and I have won first prize in a European lotto?
No, it means someone loaded up this page, without being logged in, and it showed up pretty much the same as when you are logged in. There may be an RFE for bugzilla to not show email addresses.
Attachment #128909 - Flags: review?(blizzard) → review+
Attachment #128910 - Flags: review?(blizzard) → review+
Attachment #128909 - Flags: superreview?(bryner)
Attachment #128910 - Flags: superreview?(bryner)
Comment on attachment 128910 [details] [diff] [review] More specific Xlib patch sr=bryner (for the "patch with style cleanup", but putting it here since that's where blizzard's r= is)
Attachment #128910 - Flags: superreview?(bryner) → superreview+
Attachment #128909 - Flags: superreview?(bryner) → superreview+
Blocks: 223607
bryner, the "patch with style cleanup" and the patches I asked you for sr on (and which you put the sr+ flag on) are totally different. The former patches gtk2; the patches you sr'ed patch gtk and xlib. Could you please take a look at the patches I actually asked you to sr? The "with style cleanup" patch is actually checked in and should be marked obsolete, probably...
For that matter, has someone tested the GTK and Xlib patches? See bug 223607 comment 12 -- it sure sounds like the GTK one, at least, does not do the job....
*** Bug 225186 has been marked as a duplicate of this bug. ***
I'm still seeing this bug after applying the gtk1 patch.
Blocks: 225478
Andrej, Kenneth, any idea why this patch does not work for GTK1? It'd be good to get this fixed.... :(
The switch statement had the two calls to the helper functions backwards. The enter helper was being called for leave events and vice versa. This patch switches the calls to the helpers around. I've also reworked it a bit trying to copy the style changes from the final gtk2 patch. With this patch installed, I can't reproduce the problem with a gtk build.
Attachment #128909 - Attachment is obsolete: true
Comment on attachment 135427 [details] [diff] [review] Reworked gtk patch Oh, duh. sr=bzbarsky; chris, could you possibly review this? It'd be good to fix this for 1.6b... Kenneth, mind posting the equivalent xlib patch?
Attachment #135427 - Flags: superreview+
Attachment #135427 - Flags: review?(blizzard)
Blocks: 225607
I tested the xlib patch, and it's correct as-is. The xlib port has a problem with the test case; the screen only turns blue if the interval between mouse down and mouse up is "short", and it doesn't change from blue back to white until the mouse is moved. But these problems can be reproduced with or without the patch, so I presume they're unrelated to the issue at hand.
Ah, ok.
Requesting blocking 1.6b for this.... This makes all sorts of JS and CSS menus on various sites completely unusable for users running the affected window managers (which happen to be the default KDE and GNOME window managers, among others).
Flags: blocking1.6b?
2003111611 + Patch 135472 makes things happy on a GTK build. Test case (attachment 51575 [details]) works as expected when patch is applied, and breaks as expected when patch is not applied. I humbly throw my request in with Boris' - Please make this 1.6b blocking.
+
Attachment #135427 - Flags: review?(blizzard) → review+
Checking in widget/src/gtk/nsWindow.cpp; /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v <-- nsWindow.cpp new revision: 1.414; previous revision: 1.413 done Checking in widget/src/xlib/nsAppShell.cpp; /cvsroot/mozilla/widget/src/xlib/nsAppShell.cpp,v <-- nsAppShell.cpp new revision: 1.86; previous revision: 1.85 done Someone who actually saw this bug should test tomorrow's builds and resolve as appropriate, and it would be good if people retested the dependent bugs...
Does a private build count? I've rebuilt following the checkin (and deleting the file that contained the privately applied patch). Test case works as expected. Also addresses bug 223607.
I've verified that this checkin addresses the test cases in bug 113492, bug 221957, bug 223607 and bug 225607.
*** Bug 221957 has been marked as a duplicate of this bug. ***
*** Bug 225607 has been marked as a duplicate of this bug. ***
This is fixed. Thanks for the patches, everyone who contributed!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
When I go to the Nightly Build page, the latest nightly build for Linux is for 10-Nov-2003. Will there be a nightly build today for Linux with this fix included? Thanks.
No idea why the Linux nightlies haven't been linked into the "latest" dir. The most recent build I see that would (probably) contain this fix is at: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-11-17-10-trunk/ I have no idea of the quality of this build.
Flags: blocking1.6b?
*** Bug 227015 has been marked as a duplicate of this bug. ***
*** Bug 199787 has been marked as a duplicate of this bug. ***
*** Bug 202039 has been marked as a duplicate of this bug. ***
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: