improper mouse hover behavior with links

[Michael Marley]

Binary package hint: firefox-3.1

Using Firefox 3.1 on Kubuntu 9.04 Jaunty, if I move the mouse over a link, the hover function does not work properly. If the mouse is stopped over a link, it remains as the standard cursor. If it is moving, then it rapidly alternates between the standard cursor and the link select cursor. This only happens if at some point I have moused over one of the buttons in the Firefox chrome. I have tried launching Firefox with the -safe-mode switch, but this does not affect the problem.

This problem affects functionality because some websites use menus that appear when a link is moused over, and this problem keeps the menu from staying on the screen.

[Testcase]
open firefox, move into main window, then move up into
menu bar, back into main window and hover over a link. The cursor immediately
changes back to the normal cursor.

[Lmage11 (lmage11)]

Sorry for the terrible summary, but I really don't know how else to describe this problem. It's manifesting in two ways that I can see:

1. In Firefox, sometimes moving the mouse over a link only changes the cursor for the fraction of a second in which the cursor is actually moving. When the cursor is not moving and it's on a link, it just uses the normal cursor image. This doesn't always happen, and I don't know what triggers it.

2. My fluxbox toolbar (which is set up to auto-hide) only shows up if the mouse is all the way at the bottom. If I move the mouse to the bottom so that the toolbar shows up and then move it up a little so as to click something on the toolbar, the toolbar disappears. This seems to always happen. If I move my mouse to a certain place (very close to the bottom of the screen, but not right at the bottom), I can get the toolbar to rapidly show and hide itself without moving the cursor.

I am using server 1.6 rc3. Neither of these problems existed when I was using 1.5.x. I do not actually have any proof other than that principle (can't remember who it's named after) that says that many problems are usually caused by just a few coding errors. And also they both have to do with input.

[Eric Anholt (eric-anholt)]

I see 1) as well, and have been for about 2-3 weeks I'd say. Meant to bisect, but I suck.

[Lmage11 (lmage11)]

Yeah, I suck too. :-/

I wish it was possible to integrate git-bisect with portage. I'd be much more willing to do it. As it is, however, if you want a bisect from me I think you'll have to wait until I have some free time to figure out how the hell I would even do a bisect without overriding portage in an overly damaging way.

[Lmage11 (lmage11)]

Errm, I meant "I don't actually have any proof that these two problems are related other than that principle (can't remember who it's named after) that says that many problems are usually caused by just a few coding errors". Sorry for the noise.

[Peter Hutterer (peter-hutterer)]

On Sun, Dec 14, 2008 at 07:39:10PM -0800, <email address hidden> wrote:
> 1. In Firefox, sometimes moving the mouse over a link only changes the cursor
> for the fraction of a second in which the cursor is actually moving. When the
> cursor is not moving and it's on a link, it just uses the normal cursor image.
> This doesn't always happen, and I don't know what triggers it.

verified, reproducable. running firefox through xmond reveals that it's
usually some order of:

<- MotionEvent [event=0xABCD]
-> ChangeWindowAttributes [link cursor]
-> TranslateCoordinates [0xABCD, 0, 0]
some more of the TC request, then some create pixmap/copy area/free pixmap
-> ChangeWindowAttributes [normal cursor]
-> TranslateCoordinates [0xABCD, 0, 0]

I have no idea why or what that is supposed to do. First one to bisect wins.

[Peter Hutterer (peter-hutterer)]

Still bisecting, last BAD version tested:

commit f3edc1fb0210149f35eab4e413700b5c4ac48214
Author: Keith Packard <email address hidden>
Date: Tue Nov 25 23:15:35 2008 -0800

    New version of dolt

I haven't found a good version yet. So if you want to start bisecting, start
with a commit earlier than that.

[Peter Hutterer (peter-hutterer)]

Seems to be caused by the new enter/leave model added with the patches 5e48f5e2dd2dec7cfd1fa40b61e25123dfca515e through to 3e6da1636093d7dc98baac40544c0b0fb7fd8aec.

Making this a 1.6 blocker.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=21191)
0001-dix-don-t-set-the-child-window-for-non-virtual-Ente.patch

This patch should fix the issue. Problem was a wrong implementation of the protocol spec. The thing that triggered it was a LeaveNotify event with detail NotifyInferior that had the child window set to a value other than None. This again triggered something internal in firefox and it would keep changing the cursor window back to the normal one instead of the link cursor.

Reproduceble testcase: open firefox, move into main window, then move up into menu bar, back into main window and hover over a link. The cursor immediately changes back to the normal cursor.

The patch sets the "child" field to None for all events with NotifyInferior. Only NotifyVirtual may have the "child" field set to a window.

[Lmage11 (lmage11)]

From the (admittedly limited) testing I've done with this patch, I think I can confirm that it fixes both of my issues. Thanks!

[Keith Packard (keithp)]

Reading through the protocol spec reminds me that all LeaveNotify events are generated before any EnterNotify events for the same action. The comments in enterleave.c don't make it clear if this holds for the new model.

[Peter Hutterer (peter-hutterer)]

It holds for the new model, but only in a localised fashion. The extreme case
for a nonlinear move from A-B may cause three different Enter/Leave runs.
The pointer simultaneously appears to move from A to child(A), Ancestor(A,B)
to Parent(B) and child(B) to B.

For each of the three, the LeaveNotifies are sent before the EnterNotifies.

[Peter Hutterer (peter-hutterer)]

See also: http://lists.freedesktop.org/archives/xorg/2008-December/041559.html

[Peter Hutterer (peter-hutterer)]

Changing title to describe the bug better.

[Fdo (fdo)]

ACK on the patch fixing things for me.

[Lmage11 (lmage11)]

Is a fix for this going to be committed anytime soon...?

[Michael Marley (mamarley)]

Binary package hint: firefox-3.1

Using Firefox 3.1 on Kubuntu 9.04 Jaunty, if I move the mouse over a link, the hover function does not work properly. If the mouse is stopped over a link, it remains as the standard cursor. If it is moving, then it rapidly alternates between the standard cursor and the link select cursor. This only happens if at some point I have moused over one of the buttons in the Firefox chrome. I have tried launching Firefox with the -safe-mode switch, but this does not affect the problem.

[Alexander Sack (asac)]

the interesting thing here is that it doesn't happen on intrepid. Upstream bug DB doesnt have such a report either. I suspect that some X part caused this. Will add xorg target too to get X maintainer opinion. Bryce, Timo ... any idea what might have changed in X?

[Alexander Sack (asac)]

also happens in firefox-3.0 ... but setting invalid, because nothing changed in firefox-3.0.

[Alexander Sack (asac)]

same problem in unchanged ffox 3.0 seem to indicate that its really X. Subscribing to bug so I can better follow discussion.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #14)
> Is a fix for this going to be committed anytime soon...?

We're still waiting for the focus model to be implemented fully. It's mostly there, but I'm missing a few corner cases. This patch is just a quickfix that doesn't fix the root cause of the problem.

[Timo Aaltonen (tjaalton)]

it's known upstream, but I don't have the bug reference at hand right now.

[Michael Marley (mamarley)]

Here is a link to the upstream bug: http://bugs.freedesktop.org/show_bug.cgi?id=19086

[Timo Aaltonen (tjaalton)]

yep, and there's a patch which should fix it, but not yet applied upstream.

[Eric Appleman (erappleman)]

This bug also affects the autocomplete function of the Firefox address bar.

[Eric Appleman (erappleman)]

this bug also affects the autocomplete feature of the firefox address bar.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=21665)
0001-dix-re-implement-enter-leave-model.patch

This is the reimplemented enter/leave model that fixes this bug. I haven't found any issues with it yet, so please give this a good test and report back. I intend to push this ASAP.

[Fdo (fdo)]

I presume this patch is for master rather than the 1.6 branch? It certainly doesn't apply cleanly on my 1.6 clone. Should this be ported to 1.6 for inclusion there? (I need the previous patch so I presume this is to be the case?) Should I just try and merge it manually or should I also cherry-pick the master changes to enterleave?

Essentially this patch does not apply to 1.6. due to the changes in:

commit aba1cbaadcde50a7a25f8aee06b66eec67a9145e
Author: Peter Hutterer <email address hidden>
Date: Fri Nov 28 09:19:49 2008 +1000

    dix: No DeviceEnterLeave events in server 1.6

Reverting the enterleave.c changes of this commit makes this patch apply cleanly, but the whole commit itself does not revert cleanly (and I have no idea of the consequences of reverting it anyway!!).

Thanks for any info you can supply to allow me to test this further :)

[Peter Hutterer (peter-hutterer)]

> I presume this patch is for master rather than the 1.6 branch?

correct. I haven't started the backport to 1.6 yet, but it should be 'trivial'.
Basically anything that does DeviceEnterLeaveEvents needs to be removed.
You're probably best of applying the patch to master and then cherry-picking
it over, git-am will refuse to apply it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.5.99.3-0ubuntu4

---------------
xorg-server (2:1.5.99.3-0ubuntu4) jaunty; urgency=low

  * 155_dix-don-t-set-the-child-window-for-non-virtual-Enter-Leave-events.patch
    + Fixes issue where mouse cursor in Firefox blinks when hovering over URLs.
      Workaround from X.org upstream bug 19086. Problem was that
      LeaveNotify events with detail NotifyInferior and non-None child windows
      triggered something in firefox to switch cursor back to arrow instead of
      the link cursor. A more complete fix has been pushed to upstream git, and
      sounds like it will be backported for 1.6, at which point we can drop this
      patch. (LP: #312353)

 -- Bryce Harrington <email address hidden> Mon, 05 Jan 2009 21:53:34 -0800

[Peter Hutterer (peter-hutterer)]

Pushed to master, see the patches leading up to http://cgit.freedesktop.org/xorg/xserver/commit?id=eb2d7b3d700952ba88c77deacf687b251300e660

[Eric Appleman (erappleman)]

I think I may have found a related bug regarding autocomplete:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/315907

[Fdo (fdo)]

(In reply to comment #21)
> I think I may have found a related bug regarding autocomplete:
>
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/315907
>

While the description is a bit light and I'm not 100% sure I'd doing it right, I cannot seem to replicate this issue using the xserver-1.6-enterleave branch. I startup firefox and I can use the bar to search in my history without any problems.

[Peter Hutterer (peter-hutterer)]

Patches available for 1.6 now, see
http://lists.freedesktop.org/archives/xorg/2009-January/042308.html

And I'm so bold to claim this is fixed now.

[Vseerror (vseerror)]

do you see this problem if you use flash version 10, and FF 3.x beta http://www.mozilla.com/en-US/firefox/all-beta.html

If not, please close with resolution set to worksforme.

[Stifu (stifu)]

The problem is still there. Confirmed with today's Shiretoko build and Flash 10.

[Tyler Downer (tyler-downer)]

Can you please create a new profile and try there.
http://support.mozilla.com/en-US/kb/Profiles

[Stifu (stifu)]

It's not a profile problem. I can reproduce this bug on any PC I am (I didn't check on Linux, though. Will do).

Just move your cursor over the Flash banner very slowly, and you should see it.

[Everett Guerny (everett)]

I still sporadically see this in Firefox 3.5 on Karmic.

[Fabian Neumann (fneumann)]

Having this issue in Karmic again. Firefox 3.5.5 and mostly on the Google Reader site.

[Josh K (terlmann-deactivatedaccount)]

Might you have accidentally turned on caret browsing?

Joshuah Kuttenkuler--
Signature ends here.

________________________________
From: Fabian Neumann <email address hidden>
To: <email address hidden>
Sent: Sun, November 22, 2009 7:02:34 AM
Subject: [Bug 312353] Re: improper mouse hover behavior with links

Having this issue in Karmic again. Firefox 3.5.5 and mostly on the
Google Reader site.

--
improper mouse hover behavior with links
https://bugs.launchpad.net/bugs/312353
You received this bug notification because you are a direct subscriber
of a duplicate bug.

[chuinker (corey-corlogic)]

Am also experiencing this on the google reader site. The switching from one tab to another causes normal mouse hovering for a while, using j/k navigation keys almost immediately breaks proper hovering behavior.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8pre) Gecko/20100102 Ubuntu/9.10 (karmic) Shiretoko/3.5.8pre

[Jason Smith (jassmith)]

I can also confirm this bug is *not* fixed with the patch.

[Vetinari (vetinaria)]

ditto,

Open a website in firefox, move your mouse over the refresh-button, use alt-tab, move your mouse in the middle of the screen, alt-tab and move your cursor over a link...

Firefox 3.5.8 in Karmic.

[Artscoop93 (artscoop93)]

Same problem in Karmic, Firefox 3.5.8.

When the glitch happens, sometimes you can see that another button in the Firefox menu bars is blinking like the cursor.
As if Firefox thought the cursor was at 2 different places.

The way to reproduce the bug above doesn't work for me. I have not found the path to the glitch on my machine.

[Artscoop93 (artscoop93)]

Hello,
I found some simple way to reproduce the bug (always).
This *always* works on this site (in French) : http://www.problema.fr/content/arnaque-elisa-helene-de-bousquet-et-george-daniel-purnavel

Go to this page, click any link named "Permalien", then scroll a bit with the mouse wheel to get your mouse over a link.

[donquixote (lemon-head-bw)]

same bug here.
only seen this in firefox, and only on some links, and not before today.
lucid lynx 10.04 LTS, 64 bit.

[MarianCJC (mariancjc)]

same bug here, it happens totally randomly as far as i can tell
none of the above reproduction methods worked for me, this usually happens after one hour of browsing,
restarting firefox "solves" the problem

==
firefox: 3.6.8
ubuntu: 10.04 LTS 64 bit

[Ryan Fugger (rfugger)]

I just started seeing this bug in 10.10 (maverick), happens in both firefox 3.6.11 and 3.6.12. Seems to happen when flash is loaded, or when a javascript-heavy page is open in one of my tabs. Then, in any tab, whenever I move the mouse, scroll, type, or hover over the location bar, the cursor flickers between the "link finger" and the proper cursor for the context.

[Paul Robins (paul-wza)]

Since reinstalling with 10.10 I am also experiencing this bug. It seems to be periodic, in that if left alone, the cursor will change with a particular cycle, even if this is somewhat variable.

This exists even if using the stable xorg updates PPA. It is quite a major usability issue, and is probably going to force me onto Chrome.

[Tyler Downer (tyler-downer)]

Does this happen with Firefox 3.6.13 or later in a fresh profile with flash 10.1 r101 or later?

[Stifu (stifu)]

Yes, it still happens (with Minefield). It's subtle, though.
As you move the cursor over the banner, it quickly switches from arrow to hand, then back to arrow again, and finally to hand. It shouldn't turn back to arrow.

[Ryan Fugger (rfugger)]

This is apparently also a Firefox bug in Windows, so maybe "invalid" isn't the correct designation here:

http://support.mozilla.com/en-US/questions/748197

[Ryan Fugger (rfugger)]

I can confirm this bug on Ubuntu with Firefox 3.6.13.

[Ryan Fugger (rfugger)]

See also: http://support.mozilla.com/en-US/questions/748197

[Abhishek Shah (abhishekshah33)]

Able to reproduce on FF4 b9 and Shockwave Flash 10.1r102
Platform: Windows7 32 bit

[Tyler Downer (tyler-downer)]

No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

[Stifu (stifu)]

Err, I did reply. And stated it still happens. So did others. But whatever.

[Ryan Fugger (rfugger)]

I haven't been able to replicate this bug on a fresh profile, after a few minutes of browsing. However, I have not been able to find a way to replicate it reliably with my normal profile. It seems to eventually just happen when I'm watching youtube videos. So I can't say for sure that it wouldn't occur with a fresh profile.

[Preston Connors (prestonconnors)]

I can replicate this bug consistently on a website that uses javascript code from jQuery, Twitter, and Facebook. I can give the link to the website if desired (it is a website I developed) or the direct link to the simple javascript file so please let me know if that is desired. It appears to happen after a setTimeout is triggered to a javascript function that does innerHTML. The innerHTML file uses data from an XMLHttpRequest (AJAX) to replace data in a div.

Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick
Architecture: x86_64

Mozilla Firefox 3.6.17, Copyright (c) 1998 - 2011 mozilla.org

[Preston Connors (prestonconnors)]

Please disregard comment #59 because the issue was an error in the javascript that was causing a recursive function to be called via javascript improperly. Once this was fixed the flashing hover icon no longer happens.

[Tyler Downer (tyler-downer)]

Reporter, Firefox 4.0.1 has been released, and it features significant improvements over previous releases. Can you please update to Firefox 4.0.1 or later, and retest your bug? Please also create a fresh profile (
http://support.mozilla.com/kb/Managing+profiles), update your plugins (Flash, Java, Quicktime, Reader, etc) and update your graphics driver and Operating system to the latest versions available.

If you still continue to see this issue, please comment. If you do not, please close this bug as RESOLVED > WORKSFORME

filter: prefirefox4uncobugs

[Stifu (stifu)]

I can still see the bug.

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.