Closed Bug 498593 Opened 15 years ago Closed 15 years ago
Scrollbars are behaving strange
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090614 Minefield/3.6a1pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090614 Minefield/3.6a1pre When scrolling down with my scrollwheel, the position of the scrollbar seems to be positioned wrong. I can scroll down the entire page, but my scrollbar is going in overflow. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. Visit the link above 2. Scroll down Actual Results: When I refreshed the scrollbar worked normal again.. Expected Results: After the refresh the scrollbar was positioned in a correct relation to the scrolltop position of the page
It works fine when I tried.
I can't duplicate it anymore, should have taken a screencast, it was strange. thought at first it had something to do with the css interpretation.
This works fine for me with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090615 Minefield/3.6a1pre Can you also reproduce this in safe-mode? http://support.mozilla.com/en-US/kb/Safe+Mode
I've been seeing on a number of websites in some of the recent trunk nightlies on Windows XP. I'll try to get some STR and a regression window.
I'm seeing this odd behavior too, I don't think it's trivial at all. When it happens, the size of scrollbar grabber is not correct, usually bigger than it should be, so when you scroll by dragging the grabber, you can't get to the bottom of the page. Scrolling using the middle mouse wheel does however get to the bottom of the page, but the visuals don't match up as the grabber hits the end of the scrollbar before you stop scrolling with the wheel. I also can't reproduce this, but it happens with significant frequency. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090616 Minefield/3.6a1pre
Severity: trivial → normal
By closing all Minefield windows, then clicking on a link to this bug, I was able to consistently reproduce this issue. I've attached a screenshot.
Attachment #383852 - Attachment description: Screenshot showing incorrect scrollbar → Screenshot showing incorrect scrollbar Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090617 Minefield/3.6a1pre
Comment on attachment 383852 [details] Screenshot showing incorrect scrollbar Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090617 Minefield/3.6a1pre
Attachment #383852 - Attachment description: Screenshot showing incorrect scrollbar Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090617 Minefield/3.6a1pre → Screenshot showing incorrect scrollbar
Reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090613 Minefield/3.6a1pre after about 30 minutes of browsing.
I'm going to guess that this was caused by bug 492837. That would fit into the general timeframe of when this broke.
Good?: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Minefield/3.6a1pre Bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090612 Minefield/3.6a1pre http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4430cae50dad&tochange=860a9acc39b1
Good?: http://hg.mozilla.org/mozilla-central/rev/9eed09531a50 Bad: http://hg.mozilla.org/mozilla-central/rev/af7c59f1634a So it's bug 492837. Still don't have any STR, though.
Changing summary to reflect that this can also occur with horizontal scrollbars.
Summary: Vertical scrollbar is behaving strange → Scrollbars are behaving strange
There's a standalone testcase attached to bug 498257 that reproduces this on every load (assuming the window is small enough that a scrollbar is needed).
I've seen this a few times on Windows trunk nightlies. Currently I have a bugzilla attachment edit page open, where the patch viewer iframe's scrollbar thinks the document is much shorter than it actually is.
roc, do we end up not setting up the callback on the next time through or something?
Probably the same issue as bug 499307.
Confirming that bug 498257 was fixed by the patch for bug 478465. That's probably enough to assume that this was fixed, too.
After some heavy usage of builds before and after the checkin for bug 478465, I think I can call this one fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Depends on: 478465
Resolution: --- → FIXED
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Mass change: adding fixed1.9.2 keyword (This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)
You need to log in before you can comment on or make changes to this bug.