Closed Bug 310736 Opened 15 years ago Closed 15 years ago
Scrollbars not being recalculated on resize
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051001 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051001 Firefox/1.6a1 Appeared after resolution of Bug 307158 and is likely caused by it's fix. When the window is resized to a smaller size the horizontal scrollbar reapears as in 307158 but disappears and functions correctly when refreshed. When the window is maximised the scrollbars disapear but their space remains. After a refresh the view is corrected. It apears that the viewport size is not being refreshed correctly on resize but is on the refresh. I will add a testcase. Reproducible: Always Steps to Reproduce: 1.resize untill vertical scrollbar shows up 2.maximise 3.refresh 4.minimise 5.refresh Actual Results: Scrollbars and spaces appear and disappear Expected Results: Screen should recalculate on resize as it does on refresh.
Open testcase and resize/refresh
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
I noticed this bug too. Another peculiarity of this testcase is that the push buttons of the scrollbar are already active when there is nowhere to scroll.
re-assigning to roc per the reporter's comment that this was caused by 307158. cc'ing dbaron Do we think this is worse than what was getting fixed in 307158? Backing out 307158 may be our only re-course this close to the deadline.
Assignee: nobody → roc
307158 could be a web site breaker and is a big step back on web standardisation. Perhaps ROC can come up with a better fix?
dbaron, can you help us out on this? roc's gone and we're trying to ship something in the next day or two. We'd need something really quick and really safe :-)
It seems like the basic problem is that nsHTMLScrollFrame::ReflowScrolledFrame doesn't change the result of GetActualScrollbarSizes for the duration of the call based on its aAssumeVScroll parameter, so the actual scrollbar sizes aren't the ones that are going to be used if the current reflow returns usable results. I don't think making it do so is a good way to fix this, though.
My inclination is to back out bug 307158 because of what I said in the previous comment.
Fixed by backout, trunk and 1.8 branch.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
cleaning up a nomination flag for something we fixed.
Flags: blocking1.8b5? → blocking1.8b5+
You need to log in before you can comment on or make changes to this bug.