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)

All
macOS
defect

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.
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
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.
(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.
Flags: blocking-firefox3.1?
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
Flags: blocking1.9.1?
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
We should probably back out bug 56488.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.9.1?
You need to log in before you can comment on or make changes to this bug.