Addressbar autocomplete flaky

[Eric Appleman]

Binary package hint: mozilla-firefox

Wonderbar autocomplete doesn't work at first unless you right click in the browser.

[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...?

[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.

[Eric Appleman (erappleman)]

This bug also affects the autocomplete function 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.

[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.

[Eric Appleman (erappleman)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121711 Ubuntu/9.04 (jaunty) Firefox/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121711 Ubuntu/9.04 (jaunty) Firefox/3.0.5

Wonderbar autocomplete doesn't work at first unless you right click in the browser

Reproducible: Always

Steps to Reproduce:
1. Start Firefox
2. Try to type a URL
3. Autocomplete will not work

[Eric Appleman (erappleman)]

Binary package hint: mozilla-firefox

Wonderbar autocomplete doesn't work at first unless you right click in the browser.

[Eric Appleman (erappleman)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121711 Ubuntu/9.04 (jaunty) Firefox/3.0.5 - Build ID: 2008111616

[Eric Appleman (erappleman)]

I'd also like to change the reproducibility to sporadic.

[Highmind63 (highmind63)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
What is wonderbar, an extension? Autocomplete in the location bar (aka awesomebar) works fine for me. Can you try safe mode http://support.mozilla.com/en-US/kb/Safe+Mode

[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.

[Mak77 (mak77)]

WFM too

[John Vivirito (gnomefreak)]

Firefox 2.0 is no longer supported from us nor upstream.
This has been closed upstream due to not being able to reproduce. Feel free to comment on the upstream bug and someone will open it if the information you provide is enough to open it. Closing for now since this is not something that we will fix.

[drink (martin-espinoza)]

I don't get it, this bug was closed because it's a firefox 2 bug, but the report says it's a firefox 3 bug. I'm having the problem right now, in firefox 3. I can't tell where I am supposed to go now.

[John Vivirito (gnomefreak)]

Drink please read the upper part of bug. This was fixed in Xorg not firefox, This is a bug in firefox most likely locale problem since noone can reproduce it so the fix we made was in Xorg.

[stenzn (stenzn)]

I just recently (in the past few months) started experiencing what appears to be the same issue in maverick on both Firefox 4.0.1 AND 3.6.17, and right-clicking did indeed make it work again- otherwise nothing seemed to. It's very sporadic, but once it does it, it doesn't seem to work again (until a restart?) I generally leave Firefox open, but sometimes close it every day or so to free up memory while I'm doing something else (since I leave a ton of tabs open).

This machine was a fresh install of maverick back when it was released, and xorg and whatnot is the default setup.

I know this is closed and invalid for FF and marked as fixed for xorg... but just wondering if anybody else is still seeing this.