418107 - Mouse events not tracked properly after switching tabs with keyboard

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Chris Lawson (gone)]

STR:

1) Mouse over one of the Photo Gallery links in the sidebar on the right so you get the link URL in the status bar.
2) Switch tabs with the keyboard.
3) Move the cursor somewhere else on the page.
4) Switch back to the original tab with the keyboard.
5) Observe status bar still contains URL that (very likely) does not correspond with position of cursor.

Once you've achieved this, moving the page around with the keyboard (arrow keys or PgUp/PgDn) will also fail to update the status bar, but moving the cursor with the mouse will cause an update.

I'm not sure what's going on here, but it doesn't seem to be the correct behaviour, that's for sure.

The reason I specified one of the Photo Gallery links is because this doesn't actually happen on all links. For instance, the "Post a Comment" link (at the bottom) doesn't exhibit this bug. Neither do the "Related Stories" links on the right.

Another manifestation of this (possibly a different bug, though) can also be seen with the font-size buttons (up in the top-right corner).

STR in this case are the same as above, but now you're likely to have the "Opinion" JS drop-down menu open when you complete step 5, even though you never actually put the mouse over the word "Opinion" on the original tab. (The URL in the status bar will be the URL of whatever menu item is supposedly under the cursor, probably the front page of the Opinion section.) It's possible to get the browser into a situation here where the only way to get the bad status bar text to go away is by either *clicking* the mouse or mousing over another link (both of which seem to perform a "hard-refresh" of the status bar text).

Filing in Camino for now, because I haven't tested with Minefield, but if this is an events bug like I suspect it might be, it's probably Widget:Cocoa.

This has been a problem on trunk for a *very* long time; I can't recall if I've seen it on branch or not, but I doubt it's a regression.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

> Switch tabs with the keyboard

Sorry for my ignorance, but how do you do this?

Comment 2

[philippe (part-time)]

(In reply to comment #1)
> > Switch tabs with the keyboard
> 
> Sorry for my ignorance, but how do you do this?
> 

command-option left/right arrow

Comment 3

[philippe (part-time)]

For the first case, the link is also stuck on :hover (orange colour).
This reminds me of bug 406932 (and possibly an other bug).

Based on the second example, it looks a bit like cliparea of the mouse event is suddenly covering the whole page (viewport only ?), and then catches the element that is on top (the drop down). The only way to dismiss it then is clicking somewhere in the page (which hides the drop down).

Comment 4

[Steven Michaud [:smichaud] (Retired)]

This bug gives me a headache :-)

I've now seen it in today's Camino and Minefield trunk nightlies.

But what happens seems to be sensitive to what's under the mouse when
you switch tabs.  

In any case I find it very difficult to reproduce consistently.

I don't think there's much chance this can be fixed until the STR are
better defined, and more consistent.

Comment 5

[Chris Lawson (gone)]

Well, I agree a reduced testcase might help out here, but the first STR I give are 100% reproducible for me and have been for quite some time.

If there's anything I can assist with debugging-wise, let me know.

cl

Comment 6

[philippe (part-time)]

Attachment: test case

this should be enough to illustrate the issue.

STR
1. open testcase in new tab
2. hover over link note colour/background-colour change, note url in statusbar
3. switch tab with keyboard (named tab 2)
4. move mouse (downwards is best) in that tab 2
5. return to tab with testcase.

actual result: link still in :hover state, even if mouse pointer is not over link anymore, url still displayed in statusbar.

The styling of the link has nothing to do with the issue, it only makes the issue more visible (at least, I hope :-)).

Comment 7

[Ilya Sherman]

I'm not sure I see what's different here from bug 406932.

The interesting thing is that for that one, Smokey and Philippe mentioned the problem didn't happen on trunk: can someone check if that's still the case?

Comment 8

[philippe (part-time)]

Is this still an issue for someone ?
The testcase doesn't show any problems anymore, the site given in the the URL field has changed quite a bit, and I can't repro any of the STR in comment 0.

Comment 9

[Chris Lawson (gone)]

I can't reproduce the cursor issues with the testcase or the Freep article, but I can reproduce the status bar "hang" with the Freep article by mousing over one of the photos on the right, switching tabs, moving the mouse, and switching back.

Comment 10

[philippe (part-time)]

Ah, yes. Mousing over those images indeed.
Those have 'target="popup"' and 'onclick="window.open('','popup','scrollbars=yes,width=650,height=600,left=5,top=5,resizable=yes')"'

Other links that have a both a target and an onclick attribute attached are the 'SHARE THIS ARTICLE' links. But those don't show the issue.
'target="_blank"' and 'onclick="return snl_click('facebook')"'

Comment 11

[philippe (part-time)]

Attachment: image for testcase

Comment 12

[philippe (part-time)]

Attachment: test case

A test case that reproduce the issue.
The basic thing is: 
* image without specified size
* the image is larger than the inline box for the link.

* row 1, a small image, no size specified - I can't repro the issue.
* row 2, a large image, no size specified - I can always repro the issue
* row 3, large image, size set in the stylesheet. On my local server I can't repro the issue. The same applies for size specified in the html.
but
- If I use a data:uri for the image, the issue comes back
- when testing with the image linked from the buzilla server, I randomly could repro the problem.

Comment 13

[philippe (part-time)]

(In reply to comment #12)

> - If I use a data:uri for the image, the issue comes back

On row 3, that is: the issue is always visible.

> - when testing with the image linked from the buzilla server, I randomly could
> repro the problem.

That seems related to the use of an absolute URL for the image (http://...)

The same test file is also available with relative url for the image:
http://dev.l-c-n.com/camino/tx-b418107.html

Comment 14

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]