Closed
Bug 461865
Opened 16 years ago
Closed 16 years ago
Hiding toolbar shortens vertical scroll bar, screws up YouTube videos.
Categories
(Core :: Widget: Cocoa, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 451641
People
(Reporter: fcanas, Assigned: jaas)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre
On any page with a vertical scroll bar, if I click on the button to hide the toolbar, the toolbar hides, and the length of the scroll bar stays the same s.t. the scroll bar doesn't reach the bottom of the frame anymore.
If you resize the window, the problem corrects itself. In both cases, correct drawing or not, the scroll bar functions properly, and so this could be considered a visual glitch. But it's a ~60 pixel glitch.
Reproducible: Always
Steps to Reproduce:
1.Navigate to a page taller than the window.
2.Hide the toolbar
3.look at the bottom right side of the window.
----- For YouTube problem:
With two tabs open, tabs A and B:
1.View A with YouTube video
2.Hide toolbar, observe bug.
3.View B, scrollbar flush with bottom.
4.View A, see glitch persist, and for a special bonus, if tab A has a YouTube video on it, observe mayhem!
Actual Results:
The bottom of the scroll bar becomes detatched from the bottom of the window until the toolbar is re-displayed, or the window is resized.
Expected Results:
The scroll bar should remain flush with the bottom of the viewing frame for the web page.
With two tabs open, tabs A and B:
1.View A
2.Hide toolbar, observe bug.
3.View B, scrollbar flush with bottom.
4.View A, see glitch persist, and for a special bonus, if tab A has a YouTube video on it, observe mayhem!
I've seen garbling, and even full out mirroring and flipping of you tube videos. That should go in a seperate bugm but I discovered it when filling this report out.
Comment 1•16 years ago
|
||
I've confirmed this (on OS X 10.4.11) with today's Minefield nightly.
But it doesn't happen in Firefox 3.0.3.
Do you know when it started happening (with which Minefield nightly)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am almost sure I noticed it on the 10/25 build before downloading the 10/27 build to confirm it was still there.
Did you also get the effect with YouTube videos? That one was less consistent.
FYI, my system is 10.5.5
Comment 3•16 years ago
|
||
I've found out that the problem described in the first paragraph of
comment #0 starts happening with the 2008-08-08-12-mozilla-central
nightly. Which gives this regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-07+00%3A00%3A00&enddate=2008-08-08+00%3A00%3A00
After a quick glance through the commit descriptions in this range, I
think the most likely culprit is changeset 3a1ac255e78d, the patch for
bug 428278 ("Manually calculate the overflow area contribution from
our children when not reflowing them").
To be honest I haven't yet tried to reproduce the rest of your report.
Comment 4•16 years ago
|
||
(Following up comment #3)
> After a quick glance through the commit descriptions in this range,
> I think the most likely culprit is changeset 3a1ac255e78d, the patch
> for bug 428278 ("Manually calculate the overflow area contribution
> from our children when not reflowing them").
This patch didn't trigger the problem. I tried reversing it, and the
problem still occurred.
Updated•16 years ago
|
Flags: blocking-firefox3.1?
Comment 5•16 years ago
|
||
Next most likely suspect is bug 210094, imo. Tossing this over to Layout::Form Controls to see if dbaron agrees. Toss it back over here if you think I've mistriaged.
Component: General → Layout: Form Controls
Flags: blocking-firefox3.1?
Priority: -- → P2
Product: Firefox → Core
QA Contact: general → layout.form-controls
Hardware: PowerPC → All
Updated•16 years ago
|
Flags: blocking1.9.1?
Comment 6•16 years ago
|
||
Er... what is this "button to hide the toolbar"? I don't seem to have anything like that. Makes it hard to follow the steps to reproduce.
Bug 210094 only affected code inside the fieldset layout object, and I don't see any fieldsets around. Am I missing something?
The regression range in comment 3 ends 12 hours before the nightly that the bug appears in is built. So I'm not sure it's necessarily correct. Pushing it out to actually include the nightly makes delectable things like bug 56488 be in the range. That's a much more likely culprit than anything that's been mentioned in this bug, since it explicitly changed the way we handle the relationship of the viewport scrollbars and the surrounding XUL. It also happened to be fixing a Mac-only bug with a Mac-only change.
Assignee: nobody → joshmoz
Blocks: 56488
Component: Layout: Form Controls → Widget: Cocoa
QA Contact: layout.form-controls → cocoa
Comment 7•16 years ago
|
||
We should probably back out bug 56488.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Updated•16 years ago
|
Flags: blocking1.9.1?
You need to log in
before you can comment on or make changes to this bug.
Description
•