Closed
Bug 51578
Opened 24 years ago
Closed 23 years ago
[FIX]{inc}Text Zoom doesn't work well with position:fixed elements
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla1.0
People
(Reporter: val, Assigned: bzbarsky)
References
Details
(Keywords: testcase)
Attachments
(4 files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
dbaron
:
review+
waterson
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (Win98; I) BuildID: 2000080712 If text is contained in a fixed position element, then Enlarge/Reduce Text Size in View menu causes only part of the text to change - though a refresh on that part of the window corrects it. This seems to be related to the drop-down area of the View menu: the text which is temporarily covered by the menu is the part that changes - as if only that area is being repainted when Enlarge/Reduce is clicked and the menu disappears. Reproducible: Always Steps to Reproduce: The attachment contains three 'fixed' DIVs, which each contain some text of various sorts. Use 'View=>Enlarge Text Size' a few times. Notice that the text becomes increasingly distorted. Notice that using 'View=>Reduce Text Size' doesn't quite restore the text. Cause that area of the window to refresh, and the distortion disappears.
Comment 1•24 years ago
|
||
You mention an attachment, but I don't see one here. Anyways, here's a simple testcase: <html> <head> <style> #foo { position:fixed; width:300px; border:1px solid red; top:100px; left:40px; } #bar { position:fixed; width:300px; border:1px solid red; top:200px; left:200px; } </style> </head> <body> <p id="foo">asdf asdf asdf asdf asdf asdf asdf asdf</p> <p id="bar">asdf asdf asdf asdf asdf asdf asdf asdf</p> </body> </html> When the text size is changed, the fixed positioned elements do not repaint. The relationship with menus is just coincidental: they force a repaint when the menu rolls up. But the basic problem lies in the layout engine -> Layout.
Assignee: pinkerton → clayton
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets: Menus → Layout
Ever confirmed: true
QA Contact: jrgm → petersen
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
Reassigned to erik who implemented the feature. DocumentViewerImpl::SetTextZoom() calls mPresContext->RemapStyleAndReflow() which remaps style, or forces a reflow, on the root frame. Since fixed positioned elements are children of the viewport, maybe RemapStyleAndReflow() should act on the viewport instead of the rootframe. See ConstructRootFrame() in nsCSSFrameConstructor.cpp for more information about root frame hierarchy.
Assignee: clayton → erik
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 6•24 years ago
|
||
Hi Pierre, I may be able to look into this at some point, but I don't know anything about viewports, so I will need to talk to somebody about those. Troy was the one who helped me with the RemapStyle stuff, but of course he's gone. Who should I talk to for viewport issues? Thanks! Accepting for "Future" unless somebody can make a case for Beta3 or RTM.
Comment 7•24 years ago
|
||
Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that do not have the "testcase" keyword and yet have an attachement with the word "test" in the description field. Apologies for any mistakes.
Keywords: testcase
Comment 9•24 years ago
|
||
I first noticed a bug with text size in 0.8.1. I don't think it was in 0.8. Is this the same bug that I see when I go to http://bugzilla.mozilla.org/ (with text size 100%) and then set the text size to 150%? I will attach a screenshot.
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
Sven, I would say yes. It seems to be that the layout is not triggering a reflow. Jeff.
Comment 12•24 years ago
|
||
Using build 2001032614 on GNU/Linux i386. There are similar problems on http://shrimpwars.be 1 - load the page 2 - increase the font size from 100% to 200% All texts flows over the table boundaries. The problems goes away after a manual reload action.
Comment 13•24 years ago
|
||
erik resign. reassign all his bug to ftang for now.
Assignee: erik → ftang
Status: ASSIGNED → NEW
Comment 14•24 years ago
|
||
mark all future new as assigned after move from erik to ftang
Status: NEW → ASSIGNED
Comment 16•23 years ago
|
||
pierre- can you take this bug back? erik is no longer and my group is short of hand right now.
Assignee: ftang → pierre
Status: ASSIGNED → NEW
Updated•23 years ago
|
Summary: Problem with Enlarge/Reduce Text Size in View menu for text within a position:fixed element. → [zoom]Problem with Enlarge/Reduce Text Size in View menu for text within a position:fixed element.
Updated•23 years ago
|
Summary: [zoom]Problem with Enlarge/Reduce Text Size in View menu for text within a position:fixed element. → Text Zoom doesn't work well with position:fixed elements
Comment 17•23 years ago
|
||
Also, I can see this on Mac OS 9 at: http://pixel.recoil.org Change the text size and it all goes pear shaped ;) Manual reload corrects it.
OS: Windows 98 → All
Hardware: PC → All
Comment 19•23 years ago
|
||
Bug 73165 which was closed as dup contains a testcase with fixed elements at http://www.webreference.com/html/tutorial24/example3/ When playing with this page, I noticed another problem with zoom: - go to any page (yahoo, for instance) - zoom the text to 200% - load Viewer Test #9 (or any page with frames, I guess) ==> the page doesn't appear zoomed, however the zoom ratio in the menu shows 200% and if you zoom once more, the page is displayed at 300%.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
Updated•23 years ago
|
Keywords: mozilla1.0
Comment 20•23 years ago
|
||
Moving to mozilla1.1. Engineers are overloaded!
Target Milestone: mozilla1.0 → mozilla1.1
Comment 21•23 years ago
|
||
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling work post Mozilla1.0.
Priority: P3 → P1
Target Milestone: mozilla1.1 → Future
Comment 23•23 years ago
|
||
Seems like an incremental reflow issue.
Summary: Text Zoom doesn't work well with position:fixed elements → {inc}Text Zoom doesn't work well with position:fixed elements
![]() |
Assignee | |
Comment 24•23 years ago
|
||
This seems to be a layout bug.... We call nsPresContext::ClearStyleDataAndReflow() which sees that the root frame is an nsIBox and calls MarkStyleChange() on it. Now nsBox::MarkStyleChange() goes through, does not find a parent box, and takes the "get the parent frame and call ReflowDirtyChild() on it" path. The problem is, the resulting reflow state has eReflowReason_Incremental as the reason, instead of eReflowReason_StyleChange. So the viewport doesn't bother to reflow the fixed frames.... It seems that MarkStyleChange should trigger a reflow with eReflowReason_StyleChange as the reason, no? But apparently any reflow state that has a reflow command has a reflow reason of eReflowReason_Incremental?? (according to comments in nsHTMLReflowState.h). So there are three possible approaches to this bug: 1) Reflow the root frame's viewport parent instead of the root frame 2) Make nsBox::MarkStyleChange() generate a eReflowReason_StyleChange reflow 3) Make nsViewportFrame handle eReflowReason_Incremental reflows with a eReflowType_StyleChanged type as stylechange reflows. Of these, approach #2 seems more correct to me, based on my rather meager understanding of how things work....
![]() |
Assignee | |
Comment 25•23 years ago
|
||
After talking to waterson, it looks like this "optimization" is just misguided....
Comment 26•23 years ago
|
||
Comment on attachment 81329 [details] [diff] [review] Patch v1.0 r=dbaron
Attachment #81329 -
Flags: review+
Comment 28•23 years ago
|
||
Comment on attachment 81329 [details] [diff] [review] Patch v1.0 sr=waterson
Attachment #81329 -
Flags: superreview+
![]() |
Assignee | |
Comment 30•23 years ago
|
||
Fix checked into trunk; I'll ask for driver approval in a day or two once it's had time to cook.
Summary: {inc}Text Zoom doesn't work well with position:fixed elements → [FIX]{inc}Text Zoom doesn't work well with position:fixed elements
Whiteboard: fixed on trunk, cooking
Target Milestone: Future → mozilla1.0
![]() |
Assignee | |
Comment 31•23 years ago
|
||
drivers never responded to the 1.0 request... I have requested approval for 1.0.1.
Keywords: mozilla1.0.1
Comment 32•23 years ago
|
||
please checkin to the 1.0.1 branch ASAP. once there please remove the mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
![]() |
Assignee | |
Comment 33•23 years ago
|
||
fixed on 1.0.1 branch
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: mozilla1.0.1+ → fixed1.0.1
Resolution: --- → FIXED
Whiteboard: fixed on trunk, cooking
Comment 34•23 years ago
|
||
Verified in the OSX (2002-07-16-05 ) and Windows ME (2002-07-16-08) branch builds.
Keywords: verified1.0.1
You need to log in
before you can comment on or make changes to this bug.
Description
•