Closed Bug 166705 Opened 23 years ago Closed 20 years ago

[RR+placeholder]{inc}only partial redraw of restyled content.

Categories

(Core :: Layout: Positioned, defect, P2)

Product:
Core
Component:
Layout: Positioned
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: adamrice, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: testcase)

I have a web page that uses a javascript + css trick to allow users to change the root font size (specifically, the "font-size" property in the "body" selector) in the stylesheet. (shamelessly stolen from http://www.meyerweb.com/ui/setup.html) Changing the font size changes a lot of other elements that are dependent on it. Chimera immediately re-renders the simple changes correctly, but the page-layout style elements (which are sized relative to the core font size) do not get re-drawn correctly until the user resizes the window--then it is ok. The effect is only noticeable when making a big jump in point size--switching between 11 and 12 points may not reveal any problems, but switching between 12 and 16 will. Build ID is 2002080405.
adam, that build is a month old. Please retest using a recent nightly build.
Yeah, in Chimera/2002102104 we still resize the text but don't reflow the page. This also occurs in Mozilla 1.2b, so over to Browser.
Component: Page Layout → Accessibility APIs
Product: Chimera → Browser
Version: unspecified → other
Over to Layout: Fonts and Text.
Assignee: bryner → font
Component: Accessibility APIs → Layout: Fonts and Text
QA Contact: winnie → ylong
I see the problems most obviously when reducing the font size. That is, the steps to reproduce I used were: Steps to reproduce: 1. load http://www.crossroads.net/honyaku 2. enter "8" in the font size input at the bottom of the left column 3. press enter 4. resize window horizontally Expected results: * layout doesn't have overlapping after step (3), and step (4) causes no significant changes. Actual results: * layout has significant overlap between columns after step (3) which goes away after step (4) ->All/All since I see the problem on Linux, and confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
Absolute positioning, not fonts and text.
Assignee: font → position
Component: Layout: Fonts and Text → Layout: R & A Pos
QA Contact: ylong → madhur
Summary: only partial redraw of restyled content. → {inc}only partial redraw of restyled content.
This looks like fallout from bug 146831 -- our rect has not changed and hence we don't reflow our abs pos kids on the assumption that they have not changed either... which is not true when their size depeds on the font-size as it does here.
Er, never mind that. Why is the reflow reason "incremental" here? Should it not be "stylechange"?
It should be stylechange. I was just about to say the same thing after reading your first comment.
Argh. I need to learn to read! The site sets .style.fontSize on the <body>. So we target a style-changed reflow at the <body>, but the absolutely positioned frames are hanging off the <html>, since that's the absolute containing block. So they get reflown when the <html> gets reflown, at which point the reflow is most certainly still incremental....
Summary: {inc}only partial redraw of restyled content. → [RR+placeholder]{inc}only partial redraw of restyled content.
seeing the bug on win2k, as well. adding KW : testcase
Keywords: testcase
Priority: -- → P2
Target Milestone: --- → Future
This is similar to bug 175364, but might not be a true duplicate, so marking as a dependency.
Depends on: 175364
Blocks: 224101
There's no testcase in this bug (the site has changed). Reporter, is this still an issue with today's build or a newer one?
I'm marking this WFM. Please reopen if an testcase/url is posted that still reproduces this bug in current trunk build.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.