492145 - YouTube video browse page jumping all over the place

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090507 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090507 Minefield/3.6a1pre

When moving the mouse randomly over the video thumbnails on the YouTube video browse page, the page jumps around as content is momentarily shifted out of place.

This is a regression as follows:

Works (no jumping):
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090505
Minefield/3.6a1pre ID:20090505041741

Fails (jumps around):
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090506
Minefield/3.6a1pre ID:20090506045618

I suspect Bug 67752 may be the culprit


Reproducible: Always

Steps to Reproduce:
1. Visit the linked URL
2. Move your mouse pointer randomly all over the thumbnail pictures and text.
3. Notice that page content jumps around as things are momentarily shifted out of place.

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Wow, that is indeed bad.  See same on Vista HP...
Setting to New..

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090508 Minefield/3.6a1pre Firefox/3.0.7 ID:20090508101853

Comment 2

[Boris Zbarsky [:bzbarsky]]

Exciting.  This is actually more or less expected behavior with interruptible reflow, sort of.  At least as long as we consider mouse moves to be user events....

This is sort of what roc was worried about with mouse moves, though.  It'd be pretty easy to not treat those as user events on Mac and Windows, I think.  On Linux, it'd be more or less rocket science.  :(

Comment 3

[IU]

Attachment: test case [youtube.com/browse page]

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

Re-testing this bug with the latest hourly Minefiled build, the page now behaves correctly, i.e.: no jumping around.  Hard to say what/when it got fixed, or if Youtube did something.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090715 Minefield/3.6a1pre Firefox/3.0.11 ID:20090715134535

changset: http://hg.mozilla.org/mozilla-central/rev/d190d9b6ccd1

Comment 5

[IU]

You're right.  Now WFM with html5.enable = false|true.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/2008052906 Firefox/3.2a1pre ID:20090719043021

http://hg.mozilla.org/mozilla-central/rev/f92608198566

If no nays by tomorrow evening, I'll mark this as WFM

Comment 6

[Boris Zbarsky [:bzbarsky]]

Please hold off on marking anything until I get a chance to figure out when the behavior changed.  If someone else has time to do that, that would be a big help.

There should have been no behavior change here; if there was, something is broken.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK, the behavior changed between 2009-06-23-03 (rev: 28aa23105a9e) and 2009-06-24-03 (rev: 5fe89f2c22f0).

Pushlog:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=28aa23105a9e&tochange=5fe89f2c22f0

Interesting.  Bug 478465 landed in that range.  Maybe the scrollframe here was just ending up all bogus!

Comment 8

[Boris Zbarsky [:bzbarsky]]

Well, local bisection indicates this was fixed by the patch for bug 495385.  roc, any idea how that would affect this, other than perhaps by dropping the number of lines involved under 200?

Comment 9

[Boris Zbarsky [:bzbarsky]]

It'd be nice if someone could create a more minimal (not minimal, just less css-and-stuff; still need enough content to trigger interrupts) testcase from the page; I should be able to easily modify that to trigger this on trunk.

Comment 10

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

(In reply to comment #8)
> roc, any idea how that would affect this, other than perhaps by dropping the
> number of lines involved under 200?

No.

Seems to me that problems like this would be greatly reduced if we always let reflow run for a minimum amount of time before interruption. Then if a reflow happens "fast enough" it will never be interrupted.

Comment 11

[[not reading bugmail]]

bz, roc, this isn't bug 507402 is it?

I just tried today's nightly and it seems that the testcase here is fine.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090826 Minefield/3.7a1pre

And this also looks a lot like the testcase I saw and filed for bug 511816.  

IU, is this fixed by bug 507402?  or is this still different.

Comment 12

[[not reading bugmail]]

Since I cannot seem to find an older build to make any sort of informed comment here, or open the testcase file, I guess after more thinking at least the actual flash plugins don't move around after bug 507402 with this URL testcase.  

I found the mouse wheel for bug 511816 was just affecting the plugin position relative to the page, but I wasn't seeing mouseover reflow problems that I was aware of.  

Are there screen shots of this problem's behavior in the compressed testcase file?

Comment 13

[Kevin Brosnan]

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Comment 14

[[not reading bugmail]]

Ah, thanks Kevin.  

Now i see the mouseover plugin reflow/jumpy page issue with an older build. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090515 Minefield/3.6a1pre

To summarize then, just confirming then that bug 507402 wasn't a problem at the time this bug surfaced on this particular older build and indeed some kind of reflow issue on a mouse event.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> I just tried today's nightly and it seems that the testcase here is fine.  

See comment 4 through comment 8.  Now could we _please_ not add more noise to this bug?  :(

Comment 16

[Boris Zbarsky [:bzbarsky]]

I can't reproduce this anymore even with the old builds.  Looks like the page changed.  :(

Comment 17

[IU]

(In reply to comment #16)
> I can't reproduce this anymore even with the old builds.  Looks like the page
> changed.  :(

Can anything be made of the attached test case?

Comment 18

[Boris Zbarsky [:bzbarsky]]

I don't know; it's compressed in a format I have no way of decompressing, offhand.

Comment 19

[philippe (part-time)]

Attachment: test case [youtube.com/browse page] - zipped

(In reply to comment #18)
> I don't know; it's compressed in a format I have no way of decompressing,
> offhand.

I saved it locally, uncompressed and then zipped it.

Fwiw, I don't see any jumping around on the latest OS X Minefield nightly.

PS - Boris: get The Unarchiver, it opens about everything on OS X
http://wakaba.c3.cx/s/apps/unarchiver.html

Comment 20

[Boris Zbarsky [:bzbarsky]]

Aha!  That does show the bug in the old builds.  Once m-c builds finish rebuilding (so effectively Monday) I'll check whether the fix for bug 519590 fixes the issue for good.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Excellent.  The patch for bug 519590 fixes this like a charm.  I can reproduce in a current debug build using the attachment from comment 19 if I use:

 GECKO_REFLOW_INTERRUPT_CHECKS_TO_SKIP=20 GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=-1

but not if I just use:

 GECKO_REFLOW_INTERRUPT_CHECKS_TO_SKIP=20