Closed Bug 102578 Opened 23 years ago Closed 21 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: 23 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: 23 years ago → 21 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: