315186 - Dock and page flicker on mouseover (regression).

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[Julien Cayzac]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

When moving the mouse over page bottom's dock items, the dock flickers as well as the page beneath.
It worked perfectly with Firefox prior to 1.5 versions.
It also works (minus the 'position:fixed' thing which is not supported) in Internet Explorer 6.


Reproducible: Always

Steps to Reproduce:
1. open the aforementionned address in firefox 1.5 beta or rc1 (don't know about alpha)
2. move the mouse over dock's items at page bottom
3. 

Actual Results:  
everything goes wrong. it didn't in ff1.0.x

Expected Results:  
The dock should not flicker. Nor the page beneath.

I think there's a bug in firefox repositionning the dock, while it has the css style "position:fixed" applied and its position isn't updated at any time.
Some position-recomputing code seems to get called when it should not.

Comment 1

[Stefan Pietschmann]

confirmed. that looks nasty.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051105 Firefox/1.5 ID:2005110503

Comment 2

[Martijn Wargers (dead)]

This regressed between 2004-10-11 and 2004-10-12.
Probably a regression from fixing bug 238493.

Comment 3

[Tracy Walker [:tracy]]

confirmed with Windows 2005-11-05-03-mozilla1.8

Note: this works fine on Mac 2005-11-05-03-mozilla1.8

Comment 4

[Julien Cayzac]

About comment 3: that would mean this is not a layout/core bug? I'm not aware about mozilla's internals when it comes to ports -is there any os-dependent code in core layout?

Comment 5

[Jason Bassford]

Fixing summary - it says nothing useful as is.

Comment 6

[Asa Dotzler [:asa]]

Roc and bz, can you guys look at this and see if anything can be done in time for 1.5?

Comment 7

[Asa Dotzler [:asa]]

not going to block on a year old regression with this low visibility

Comment 8

[Julien Cayzac]

(In reply to comment #7)
> not going to block on a year old regression with this low visibility

Hmm... I agree, and I don't.
The aforementionned web page only use basic css scripting. Once ff1.5 gets released and web designers get their hands on it, they may flame about this bug unless a css workaround can easily be found (which I'm not sure about) :-/
Well, it's a marketing issue I guess :-)

Comment 9

[Boris Zbarsky [:bzbarsky]]

I really doubt there's anything safe we could do here for 1.8 even if we wanted to.

Comment 10

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

(In reply to comment #8)
> The aforementionned web page only use basic css scripting. Once ff1.5 gets
> released and web designers get their hands on it,

Many Web designers have had their hands on FF builds with this bug for a very long time.

Comment 11

[Julien Cayzac]

Another example:
http://www.ajaxify.com/run/reader/logging/realService/

The "Pattern Playlist" (upper right page corner) is a draggable transparent element. When moving it, the transparent area flickers a lot.
Works fine in internet explorer.

Comment 12

[Hiro]

(In reply to comment #11)
> Another example:
> http://www.ajaxify.com/run/reader/logging/realService/
> 
URL and this page are not found.
But in bug301149 test case, The flicker reproduces. 
https://bugzilla.mozilla.org/attachment.cgi?id=189639

Mac OS X 10.3.9
Camino 2006101121 (v1.2+)
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061012 Minefield/3.0a1

Comment 13

[j.j.]

Are bug 389695 and bug 340628 related/dups?
(Bug 389695 has a testcase)

Comment 14

[j.j.]

(Assuming that comment 12 is correct)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Uh... no, not at all.  The regression range is wrong for that.  See comment 2.

This is probably INCOMPLETE due to lack of testcase, though....

Comment 16

[j.j.]

I read this bug and bug 238493. The fix for the latter (suspected to regress here) was checked in 2004-10-11 in 1.8a, not in 1.7 branch. Bug 302561 was reported 2005-07 against 1.8b4 (without regression date). 

I see no contradiction calling this a dup of 302561 (as an assumpion, of course, and to get rid of this zombie, and to have one more target to hit before reporting duplicates).

Anyway, this bug is dead and should be closed. It's REOPEND state isn't helpful at all.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Bug 206691 was introduced by the "reflow triggers mousemove" changes, which have a checkin date different from this bug's regression date.

Comment 18

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

(In reply to comment #17)
> Bug 206691 was introduced by the "reflow triggers mousemove" changes, which
> have a checkin date different from this bug's regression date.

I'm assuming you mean bug 302561.  In any case, bug 302561 was not introduced by the "reflow triggers mousemove" changes -- I intentionally made sure it wasn't.  I believe it regressed when we started doing style reresolves asynchronously (which is the theory that led me to a fix that works), although I haven't confirmed that.

That, however, also doesn't match the regression range in comment 2.

Comment 19

[BugBot [:suhaib / :marco]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Boris Zbarsky [:bzbarsky] from comment #15)

This is probably INCOMPLETE due to lack of testcase, though....

Per comment 2, the bug's URL field (http://jcayzac.brainlex.com/extDock2/ ) and the ajaxify example are server-not-found.

And the testcase from comment 12 does still flicker, but that's because it has :hover-triggered display:none, which makes sense as something that would potentially flicker on hover. (And that sounds quite different from what was described in comment 0.)