Closed Bug 279579 Opened 20 years ago Closed 20 years ago

Absolutely positioned image shrinks in size when viewport is smaller than image

Categories

(Core :: Layout: Positioned, defect)

Product:
Core
Component:
Layout: Positioned
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: MatsPalmgren_bugz)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(3 files, 1 obsolete file)

img for testcase
10.66 KB, image/gif
Details
Testcase
278 bytes, text/html
Details
Patch rev. 1
2.17 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
See upcoming testcase.

An absolutely positioned image, like: <img src="bk1.gif" style="position:
absolute; top: 0pt; left: 0pt;">
that is larger than the viewports gets shrinked in current trunk builds. That
should not happen, since right and bottom are auto.

The bug does not occur in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041205
Firefox/1.0+ 8:00am
But the bug does occur in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041206
Firefox/1.0+ 8:04am

Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-12-05+07%3A00%3A00&maxdate=2004-12-06+08%3A00%3A00&cvsroot=%2Fcvsroot

I suspect "Patch rev. 10" from bug 201897 might be the cause of this bug, that's
why I cc-ed you Mats.
Attached image img for testcase — 

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase (obsolete)
        — 
      

    


  
To reproduce the bug:
Resize the window till the viewport is smaller than the image, the image should
not shrink to fit in the viewport, but it does that in current trunk builds.

    
    

    
  
Comment on attachment 172253 [details]
Testcase

><HTML><HEAD><TITLE>Testcase bug - Absolutely positioned image shrinks in size when viewport is smaller than image</TITLE></HEAD>
><BODY>
><IMG style="position: absolute; top: 0pt; left: 0pt;" src="https://bugzilla.mozilla.org/attachment.cgi?id=172252"/>
></BODY></HTML>

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase
        — 
      

    


  
Sorry, typo in the previous testcase. I tried to repair it, but that didn't
work.

    
  

        Attachment #172253 -
        Attachment is obsolete: true

    
  
Keywords: regression, 
          
            testcase

    
    

    
  
This is definitely a regression from the followup fix for bug 201897.

The problem is that this code clobbers kidReflowState.mComputedMaxWidth to be no
more than the availWidth.  But images actually follow the mComputedMaxWidth,
unlike some other frames, apparently.  So the image sizes itself to be no wider
than the computed max width.

Note that the MEW for images is just the computed width, whatever that is, so
the SHRINK_TO_FIT_MEW thing is never triggered.

Also note that this code is possibly setting mComputedMaxWidth to be less than
mComputedWidth (which seems wrong; I thought I'd commented on that in bug 201897).

To mats. We really want to fix this for 1.8...
Assignee: nobody → mats.palmgren
Severity: normal → major
Flags: blocking1.8b?
OS: Windows 2000 → All
Hardware: PC → All

    
    

    
  
Oops, nice catch Martijn, thanks.
Status: NEW → ASSIGNED

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch rev. 1
        — 
          — Splinter Review
      

    


  
This take care of the replaced elements regression (CSS 10.3.7 does not apply),

(the code path is now exactly the same as before bug 201897 for them).

    
    

    
  
Comment on attachment 172273 [details] [diff] [review]
Patch rev. 1

Looks reasonable.  Land it.  ;)

        Attachment #172273 -
        Flags: superreview+

        Attachment #172273 -
        Flags: review+

    
    

    
  
(In reply to comment #5)
> Also note that this code is possibly setting mComputedMaxWidth to be less than
> mComputedWidth (which seems wrong; I thought I'd commented on that in bug
> 201897).

I think I did address it:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsAbsoluteContainingBlock.cpp&mark=567-570#560

which can result in mComputedMaxWidth < mComputedWidth only if
mComputedMinWidth > mComputedMaxWidth but I think David pointed out somewhere
that 'min-width' should have priority over 'max-width'?
Or did you mean some other code?



    
    

    
  
In that block (SHRINK_TO_FIT_AVAILWIDTH) and during the first reflow 
kidReflowState.mComputedWidth is always NS_SHRINKWRAPWIDTH (and was so
also before bug 201897). I'm guessing this is one of the reasons for the
remaining problem (bug 275179) - we shouldn't use an unconstrained
mComputedWidth and use a "fake" mComputedMaxWidth to limit the reflow, but
I don't dare change it at this point without *a lot* of thinking/testing.
I hope you're not too dissappointed if I deflect that issue to bug 275179 ...

I'll check in the current patch, which is low risc.

    
    

    
  
Checked in 2005-01-24 13:45 PDT.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
Oh, definitely.  I'm not suggesting we try to fix that now.  Doing it in the 1.9
timeframe, esp. if the reflow refactoring branch lands, sounds like a much
better idea.



    
    

    
  
Verified. 
(In reply to comment #6)
> Oops, nice catch Martijn, thanks.
Well, I didn't discover this bug, it was Brent Silby in bug 234233, comment 39.

Status: RESOLVED → VERIFIED

    
    

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

    
  
Flags: blocking1.8b?

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: