Closed Bug 492145 Opened 11 years ago Closed 10 years ago
Tube video browse page jumping all over the place
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.
Component: General → Layout
Product: Firefox → Core
Version: unspecified → Trunk
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
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. :(
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
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
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.
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!
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?
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.
(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.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
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.
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?
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.
I can't reproduce this anymore even with the old builds. Looks like the page changed. :(
(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?
I don't know; it's compressed in a format I have no way of decompressing, offhand.
(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
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.
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
You need to log in before you can comment on or make changes to this bug.