Closed Bug 173072 Opened 22 years ago Closed 22 years ago

scroll bar missing after text zoom

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jmd, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Fix
5.39 KB, patch
roc
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review 
I'm only seeing this on my page.

http://jmd.us/reading-list/

I select text zoom 90%, then go back to 100%, at which point I get a grey band
on the right of the screen. Linux 2002100705. Reproducable.

Just made this page yesterday and the code isn't terribly clean due to the
truckload of work-arounds I needed to get IE to display it decently, but it is
compliant XHTML 1.0.
It's the scrollbar! That's what the bar is supposed to be. Just occured to me
the scrollbar is missing. 90% zoom didn't need the scrollbar, so when it comes
back at 100% zoom, it's not rendered properly.

Screenshot: http://jmd.us/mozilla/text-zoom-grey-bar.png
this regressed between linux trunk builds 2002092921 and 2002100104

I would suspect Views rather than Layout
Keywords: regression
*** Bug 174182 has been marked as a duplicate of this bug. ***
*** Bug 174789 has been marked as a duplicate of this bug. ***
*** Bug 176409 has been marked as a duplicate of this bug. ***
Summary: blank area added after text zoom decresed and then restored → scroll bar missing after text zoom
OS -> All
Severity -> major
Severity: normal → major
OS: Linux → All
In this URL from one of the duplicates I can see the problem:
http://www.cds-inc.com/new/ba2kv4.html
Attached patch fix (obsolete) — — Splinter Review 
This patch fixes the bug. The problem is that the scrollbar view isn't being
made visible, because the call from SyncLayout to
nsHTMLContainerFrame::SyncFrameViewAfterReflow no longer sets the view
visibility.

What I don't understand is that when nsGfxScrollFrame sets the 'collapsed'
attribute on the scrollbar frame, it should be triggering a stylechange reflow
on the scrollbar, which should be causing the view properties to be updated.
Also, things seem to be working when a resize reflow is targeted at the
document itself. So I'm a bit confused.

This patch is probably a good catch-all fix for 1.2final though. It's perfectly
safe since it basically just mimics the old behavior of
SyncFrameViewAfterReflow.
*** Bug 177897 has been marked as a duplicate of this bug. ***
*** Bug 178363 has been marked as a duplicate of this bug. ***
Comment on attachment 104605 [details] [diff] [review]
fix

r/sr=kin@netscape.com

This patch will cause SyncFrameViewGeometryDependentProperties() to be called
twice, but I'm guessing that's ok for 1.2final.

I'd still like to know if there really is a bug that needs to be fixed
somewhere in regards to the style change reflow you mentioned above.
Attachment #104605 - Flags: superreview+
adding to 1.2 blocker list.
Blocks: 1.2
Comment on attachment 104605 [details] [diff] [review]
fix

r=bzbarsky; test for perf impact on "DHTML" please...
Attachment #104605 - Flags: review+
Comment on attachment 104605 [details] [diff] [review]
fix

a=asa for checkin to the 1.2 branch (on behalf of drivers)
Attachment #104605 - Flags: approval+
Fix checked in to 1.2 branch.
No longer blocks: 1.2
this broke menus.
179459 has been filed as the result of the menu regression introduced by this fix.
Blocks: 179459
I'm going to back this out.
I backed it out from trunk and branch.
Someone should have a look on bug 172486
I think it should be marked as a DUP of this bug
*** Bug 172486 has been marked as a duplicate of this bug. ***
*** Bug 181399 has been marked as a duplicate of this bug. ***
not yet fixed in

Mozilla 1.3a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021117
==> roc
Assignee: attinasi → roc+moz
*** Bug 170454 has been marked as a duplicate of this bug. ***
I'm not seeing scrollbars when I initially open the JS console (Linux build) -
although there are enough errors to fill the console there are just gaps where
the scrollbars should be. The scrollbars appear once I close and re-open the JS
console. Is this another artefact of this bug?
URL is not longer available. Replacing it with working one. See bug 176409 for
additional details.
URL: http://jmd.us/reading-list/ → http://www.cds-inc.com/new/ba2kv4.html
Bug 183353 also demonstrates the problem

This is turning out to be very tough. There's some weird stylecontext behavior
involved.
I added printfs which clearly show that the style context for nsScrollbarFrame
at one point has an nsStyleStruct_Visibility (the struct is queried for when
nsScrollbarFrame creates its view and synchronizes the view state with the frame
style). But later, when the scrollbar "collapsed" attribute is removed, the old
style context no longer has an nsStyleStruct_Visibility. I don't know where it
went. dbaron told me that this is meant to indicate that the
nsStyleStruct_Visibility was never used, but it clearly was used and somehow it
was removed (and however it was removed, no event was generated to resynchronize
the view with the frame, which would have reacquired the visibility struct).

Changing all the calls to PeekStyleData in nsStyleStruct::CalcStyleDifference to
be GetStyleData make this problem go away. These are the only calls to
PeekStyleData. The question is, how much of a performance win is this
optimization? Getting rid of it would simplify the semantics of the style system
 because CalcStyleDifference would no longer depend on which style structs had
previously been read from a style context. And of course we could get rid of
PeekStyleData and associated logic in the style system.
OK, the problem is that nsPresContext::ClearStyleDataAndReflow clears the style
data and then only does a reflow. In fact after clearing the style data we have
to  resync the views and repaint everything as well as reflow, to make sure any
necessary style structs are reacquired to subsequent
nsStyleContext::CalcStyleDifference calls will compute correct hints. I have a
patch that does this in nsPresShell::StyleChangeReflow.

I've also analyzed other style-clearing places and adjusted them to make sure
they do the right thing.

Style clearing in nsCSSFrameConstructor worried me for a while but I think style
re-resolution ensures that any style structs present in the old style context
will be present in the new style context OR a style change hint will be issued
sufficient to ensure reloading of any cleared style structs.
Attached patch Fix — — Splinter Review 
I've also fixed up pref color changing to not reconstruct but just do
ClearStyleDataAndReflow. It appears to work fine.
Attachment #109225 - Flags: superreview?(kin)
Attachment #109225 - Flags: review?(dbaron)
Comment on attachment 109225 [details] [diff] [review]
Fix

r+sr=kin@netscape.com
Attachment #109225 - Flags: superreview?(kin) → superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 185571 has been marked as a duplicate of this bug. ***
Attachment #109225 - Flags: review?(dbaron) → review+
*** Bug 186141 has been marked as a duplicate of this bug. ***
*** Bug 186358 has been marked as a duplicate of this bug. ***
*** Bug 185326 has been marked as a duplicate of this bug. ***
*** Bug 192361 has been marked as a duplicate of this bug. ***
*** Bug 194611 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: