302561 - :hover styles that move/resize element cause endless reflow oscillation

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[shane]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412+ (KHTML, like Gecko) Safari/412.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050718 Firefox/1.0+

If the border of an element is specified to be null when hovered over, then hovering over the border 
causes the element and border to blink rapidly.

Reproducible: Always

Steps to Reproduce:
1. Open specified URL
2. Hover mouse pointer over the border that underlines XHTML
3.

Actual Results:  
Element and border blink rapidly.

I think what's happening is that, when hovering over the border, it disappears, disabling it from being 
hovered over, whereby it reappears, and can then be hovered over again, thereby repeating and thus the 
blinking.

Expected Results:  
Element and border should not blink. Hovering over the border should disable it from being displayed.

Comment 1

[shane]

Attachment: Test case for :hover border bug

Comment 2

[shane]

I was only able to test this on recent builds of Camino and Firefox for Mac OS X.

Comment 3

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050729
Firefox/1.0+ ID:2005072903
I see the described behaviour too.

Comment 4

[Peter van der Woude [:Peter6]]

*** Bug 304604 has been marked as a duplicate of this bug. ***

Comment 5

[Caleb]

I'm not sure, but is this is another case of this bug:

http://www.croczilla.com/svg/samples/opacity2/opacity2.svg

Put your mouse in the middle of the star, and move it in a diagonal movement to
the top-right. When the mouse nears the green hexagon the red stroke line is
lost around the star (it flashes as the mouse movement).

Try it a couple of times (move the mouse to different places, around the border
of the hexagon if you can't succeed.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is the right behavior, and you described it exactly in comment 0.  I don't know where your "Hovering over the border should disable it from being displayed." expected result comes from -- once there is no border, the element is not in :hover anymore, as you noted.

Comment 7

[Philip Puryear]

(In reply to comment #6)
> This is the right behavior, and you described it exactly in comment 0.  I don't
> know where your "Hovering over the border should disable it from being
> displayed." expected result comes from -- once there is no border, the element
> is not in :hover anymore, as you noted.
 
Right, but the problem is that the border _doesn't_ go away completely. When the border itself is hovered over (note: not the rest of the element, just the border itself), it dissappears and reappears rapidly, like a strobe light. If that _is_ the desired behavior, it certainly is strange.

Comment 8

[Philip Puryear]

Attachment: Testcase with a larger border

This makes it a little easier to position the mouse pointer over the element's border so the bug is a little more obvious.

Comment 9

[philippe (part-time)]

Technically, Gecko's behaviour is correct: as soon as you hover over the border, the border disappears, but then the inline-box shrinks and the pointer is out of the 'hovered' area, hence the border reappears.

Opera 9 preview and Safari do the same thing, although more slowly.

If I were to use this in a stylesheet, I would only change the color of the border (to match the background-colour) on :hover, or add padding to match the width of the border.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> that the border _doesn't_ go away completely

Sure it does.  It goes away.  The element's size changes.  The element is no longer hovered.  The :hover style no longer applies.  There is a border again.  And so forth.

Let's put this another way.  What do YOU think is the correct layout here?  And why is it correct?

Comment 11

[Philip Puryear]

I do realize that Gecko is doing what it is technically supposed to be doing, and maybe the W3C spec actually does call for this to happen (although I haven't read the spec in full). I'm just saying that the behavior is strange. Imagine, for example, that you have a hyperlink that is styled with a bottom border that will be removed on :hover. Naturally, when you mouse over that link, you expect the cursor to change to a hand and the border to dissapear. You do not expect to have the cursor flip rapidly back and forth between a pointer and a hand and to have the border flash on and off the screen. I've seen cases where this has made the entire page jiggle up and down when the cursor is at rest in one spot.

Ideally, when a web developer styles content to remove a border on hover, I believe there should be a definite hover "zone" and a definite non-hover "zone" and no interim area in which an element can be both hovered and not hovered when the cursor stays in the same spot (which kind of defies reason).

I know what Gecko's logic is here. All I'm saying is that its behavior, however intentional it may be in this instance, is a major, major annoyance.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> and maybe the W3C spec actually does call for this to happen

It does, though it has weasel-language about it being OK to change layout on hover (which means that in this testcase :hover would have absolutely no effect on that node in a UA that takes that way out).

> although I haven't read the spec in full

I highly recommend doing that before arguing about spec-compliance issues...

What is your definition of "hover" exactly, in the face of elements changing size?  I don't see a self-consistent way to define hover that satisfies your conditions, but if you do, please enlighten me.

> is a major, major annoyance.

If you have issues with the CSS spec, I suggest taking it up with [e-mail].  Please do make sure you have a proposal for how things should work in this case if you do that, though (that would be the definition I mention above).

Comment 13

[Philip Puryear]

The issue here is that the spec (correct me if I'm wrong) requires that the border be part of the element, which, in and of itself, makes sense. However, if the border weren't part of the element, then hovering over it (the border) wouldn't cause it (the border) to be removed like it is now, thus fixing the problem we're having.

Since this is a pretty nebulous spec issue, I believe I will take this up with the W3C, as you suggested. I'll post here again if I get some sort of response.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> requires that the border be part of the element

The spec doesn't define what constitutes :hover, actually.  Gecko treats it as "hover over the border-box".  Any such definition has a problem if you change the relevant dimensions in :hover, though.  Even if we defined it to be the content-box, you would get flicker with the testcase if you moved your mouse in a little from the border.

Comment 15

[j.j.]

Attachment: cross-browser testcase (compare with IE7)

* This bug breaks compatibility with IE7, Safari3b, Opera9.
* This is a regression against 1.7.5 (FF 1.0)

Perhaps it's worth to consider reopening. IE supports :hover on any Element now.
See related bug 389695 (came up in the forums).

j.j.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> * This bug breaks compatibility with IE7, Safari3b, Opera9.

What exactly do those UAs do differently from us?

Comment 18

[j.j.]

(In reply to comment #16)
> What exactly do those UAs do differently from us?
 
attachment (id=275692) (cross-browser testcase)
Move cursor over the red bar and stay there-
 red bar flickers on and off permanently with currenent trunk
 no flickering with other browsers, including FF 1.0

http://jeka.info/test/jump.htm (testcase from bug 389695 comment 3)
Move cursor over the arrows and stay there- 
 content flickers and jumps around permanently with current trunk
 no flickering and jumping with other browsers incl. FF 1.0

(Note: This bug is about borders, bug 389695 is about margins and paddings)

j.j.

Comment 19

[Boris Zbarsky [:bzbarsky]]

> Move cursor over the red bar and stay there-
> red bar flickers on and off permanently with currenent trunk

That's not the behavior I see (on Linux).  The bar is either on or off depending on whether I moved into it from above or below.

But in any case, this doesn't answer my question.  I wasn't asking what the testcase looks like in other UAs.  I was asking _why_ it looks like it does.  That is, exactly what they do differently.  If we're going to claim there's incompatible behavior, then data is needed on exactly what aspects are incompatible.

Comment 20

[j.j.]

> That's not the behavior I see (on Linux).

I did all my tests on winXP.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080705 Minefield/3.0a8pre

Comment 21

[Boris Zbarsky [:bzbarsky]]

That's fine.  My question remains, however.

Comment 23

[j.j.]

(In reply to comment #16)
> > * This bug breaks compatibility with IE7, Safari3b, Opera9.
> 
> What exactly do those UAs do differently from us?

Boris, I'm not exactly sure what you mean, seems obvious:

The :hover pseudo-class applies if
     1. the cursor is located over the box 
 and 2. the cursor is moving at the same time.

The :hover style releases if
     1. the cursor is not located over the box
        (or the box isn't displayed at all)
 and 2. the curser is moving. (Not if it remains stationary)

The last point makes the difference in Gecko. Does this answer your question?

(In reply to comment #19)
> That's not the behavior I see (on Linux).  The bar is either on or off
> depending on whether I moved into it from above or below.

Test on Windows (attachment 275692 [details]).

[ Sorry, this bugged me several times in browsing and recently by toying with -moz-transform. We need this fixed, or at least considered to be a valid bug. (This is also a regression against Gecko 1.7.5). Should I file a new bug regarding -moz-transform ? ]

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That we go out of :hover when the page moves for other reasons is a feature.  That we oscillate is a bug; I wrote code to prevent us from oscillating when we added that feature.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

My guess is that the code to prevent this in nsViewManager::ProcessSynthMouseMoveEvent and nsViewManager::SynthesizeMouseMove stopped working either (1) when we started processing style changes asynchronously or (2) when it was rewritten in the thread manager landing.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Here's a patch that I think gets us back to the old behavior of a single flicker per mouse move when in one of these bad regions of the page.

I haven't tested it much yet, and I still need to think about writing some automated tests.

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

I'm giving up on the test for now; I may come back to it.

I actually am getting the resize events as a result of the synthesized mouse moves.  However, I'm always getting the non-:hover style.  This causes the test to stop running at step3, where the coalescing check fails even though it should pass.  I need to figure out why, at some point.

Comment 29

[Boris Zbarsky [:bzbarsky]]

> The :hover pseudo-class applies if
>      1. the cursor is located over the box 
> and 2. the cursor is moving at the same time.

A bit of testing shows this to not beat all correct.  For example, scrolling the page (with mousewheel or keyboard) such that the motionless mouse cursor ends up over an element brings that element into hover in Opera and Safari.  Using a JS setTimeout to position an element under the cursor doesn't put it into hover immediately, but puts it into hover if the mouse is clicked without moving (easy with a trackpad) in all of Opera, Safari, and IE.  It also puts it into hover if any keyboard event happens in Safari.  Hovering over the border in the testcases in this bug and hitting the "shift" key over and over again is an exercise worth doing in Safari.  This is Opera/Safari on Mac, IE7 on Windows.

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

I finally got the test working (debugging the problems was a bit of a pain:  the main problem was that I need to wait for paint suppression to be over; then I discovered that I was sending events relative to divtwo instead of relative to divtwoparent).

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

So it turns out that last time, the test worked fine on its own, but it didn't when it was in an iframe.  I started off thinking it was a problem with the test, but then realized it was a problem with the code.

This fixes said problem in nsViewManager.cpp, by changing which PresShell we send the synth mouse move event through.  I'm asking roc to review this time because of the new changes.

I had to write a FindViewContaining method, which is only used when FindFloatingViewContaining comes up empty.  I think the assumptions it's making about views containing each other should be correct for non-folating views, but I'd like roc to check that.  It would be nice if there were a pre-existing way to do this, but I didn't find one.

I also changed FindFloatingViewContaining to use GetViewVisibility rather than IsViewVisible.  The only difference is that IsViewVisible walks up the view's parent chain; instead we can just cut off the recursion with GetViewVisibility.  The only functional difference should be the call to the view observer, which should only differ in the case where we're inside a hidden tab, which should never be the case if we've got the mouse position. 

Does this seem like a reasonable approach?

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So I landed this:
http://hg.mozilla.org/mozilla-central/rev/7b553bbed53d
but then had to back it out due to a crash in chrome tests:
http://hg.mozilla.org/mozilla-central/rev/212de1e1a104
http://hg.mozilla.org/mozilla-central/rev/a1547a6dd000
... which I can reproduce.

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: additional patch to fix test failures

There were crashes in chrome/browser tests related to menus.  This fixes them.  It applies on top of attachment 351261 [details] [diff] [review].

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Landed on mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/a47eccda2278

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Were you planning to land this in 1.9.1? If so, don't forget to land 468753 with it.

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I was not planning to land this in 1.9.1.

sgautherie:  Why did you nominate it for blocking?

Comment 38

[j.j.]

Because it's an bothersome bug and a forgotten regression which should be fixed?
Should be "wanted1.9.1" IMHO.
Is there any reason not to land this in 1.9.1 ?

Comment 39

[Serge Gautherie (:sgautherie)]

(In reply to comment #37)
> sgautherie:  Why did you nominate it for blocking?

In support of comment 36, to sort out if both or none of these 2 bugs should actually block.

***

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20081212 Minefield/3.2a1pre] (nightly) (W2Ksp4)

Additionally, I hoped this might fix a similar "disturbing" behavior an (old / "MsIE-designed") (restricted access) site I'm using has,
but it doesn't :-|

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 351261 [details] [diff] [review]
patch

OK, I suppose this is relatively straightforward and it does fix a pretty nasty bug that can prevent users from being able to do things like click on links.

I'll make sure to land the followup fixes along with it.

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 351261 [details] [diff] [review]
patch

a191=beltzner

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fixed on 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/24f0717b214b

Comment 44

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre Ubiquity/0.1.5 
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090130 Minefield/3.2a1pre