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)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: val, Assigned: bzbarsky)

References

Details

(Keywords: testcase)

Attachments

(4 files)

View=>Enlarge/Reduce Text Size & Fixed pos element
(deleted), text/html
Details
improved testcase
(deleted), text/html
Details
Bug after setting text size from 100% to 150%
(deleted), image/png
Details
Patch v1.0
(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.
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

  

  



    
    

    
  

      
      
      
      

        Attached file
          
        improved testcase (deleted)
        — 
      

    


  

  

  



    
    

    
  
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

    
    

    
  
See bug 51109 for another problem with TextZoom.


  

  



    
  
Status: NEW → ASSIGNED
Target Milestone: --- → Future

    
    

    
  
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.

  

  



    
    

    
  
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

    
    

    
  
Anybody have an update on this bug?

Jeff.

  

  



    
    

    
  
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.


  

  



    
    

    
  


  

  

  



    
    

    
  
Sven,

I would say yes.  It seems to be that the layout is not triggering a reflow.

Jeff.

  

  



    
    

    
  
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.




  

  



    
    

    
  
erik resign. reassign all his bug to ftang for now.


  

  


Assignee: erik → ftang
Status: ASSIGNED → NEW

    
    

    
  
mark all future new as assigned after move from erik to ftang


  

  


Status: NEW → ASSIGNED

    
    

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

  

  



    
  
Blocks: 54504

    
    

    
  
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

    
  
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.

    
  
Depends on: 95267

    
  
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

    
    

    
  
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

    
    

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

  

  



    
    

    
  
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

    
  
Keywords: mozilla1.0

    
    

    
  
Moving to mozilla1.1. Engineers are overloaded!

  

  


Target Milestone: mozilla1.0 → mozilla1.1

    
    

    
  
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

    
    

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

  

  



    
    

    
  
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

    
  
Blocks: 140599

    
    

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

  

  



    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v1.0 (deleted)
        — 
          — Splinter Review
      

    


  
After talking to waterson, it looks like this "optimization" is just
misguided....

  

  



    
    

    
  
Comment on attachment 81329 [details] [diff] [review]
Patch v1.0

r=dbaron

  

  



        Attachment #81329 -
        Flags: review+

    
    

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

  

  



    
    

    
  
Comment on attachment 81329 [details] [diff] [review]
Patch v1.0

sr=waterson

  

  



        Attachment #81329 -
        Flags: superreview+

    
    

    
  
Taking bug

  

  


Assignee: pierre → bzbarsky
Status: ASSIGNED → NEW

    
    

    
  
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

    
    

    
  
drivers never responded to the 1.0 request... I have requested approval for 1.0.1.

  

  


Keywords: mozilla1.0.1

    
    

    
  
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+

    
    

    
  
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

    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: