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

*** 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. ***

OS -> All Severity -> major

In this URL from one of the duplicates I can see the problem: http://www.cds-inc.com/new/ba2kv4.html

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.

adding to 1.2 blocker list.

Comment on attachment 104605 [details] [diff] [review] fix r=bzbarsky; test for perf impact on "DHTML" please...

Comment on attachment 104605 [details] [diff] [review] fix a=asa for checkin to the 1.2 branch (on behalf of drivers)

Fix checked in to 1.2 branch.

this broke menus.

179459 has been filed as the result of the menu regression introduced by this fix.

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

*** 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.

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.

I've also fixed up pref color changing to not reconstruct but just do ClearStyleDataAndReflow. It appears to work fine.

Comment on attachment 109225 [details] [diff] [review] Fix r+sr=kin@netscape.com

Fix checked in.

*** Bug 185571 has been marked as a duplicate of this bug. ***

*** 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. ***