Closed Bug 946235 Opened 11 years ago Closed 11 years ago

Position:sticky doesn't work correctly in flexbox

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: sjw+bugzilla, Unassigned)

References

Details

Attachments

(1 file, 3 obsolete files)

testcase2
(deleted), text/html
Details 
Since 2013-12-02 position:sticky doens't work with felxboxes in some scenarios.
STR:
-Create an element inside of a flexbox container
-use flex-grow:1 (>= 0) and position:sticky for the flex-item

Note:
I created this testcase after I found this bug. If necessary, I'll add the original file, where I notice the change.
Attached file testcase (obsolete) (deleted) — 

  

  



    
  
Blocks: 931460

    
    

    
  
Looks to me like the <div> in that testcase fills the entire height of the <body> (in both Nightly and Aurora), in which case position:sticky indeed shouldn't cause it to move as the page scrolls.

  

  


Blocks: 916315
No longer blocks: 931460

    
    

    
  
Comment 2 is right on the money.

If you drop the "flex-grow: 1" on the <div> so that it doesn't fill the whole <body>, then it behaves as you'd expect.

  

  


Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Summary: Position:sticky doesn't work correctly in felxbox → Position:sticky doesn't work correctly in flexbox

    
    

    
  

      
      
      
      

        Attached file
          
        testcase 2 (obsolete) (deleted)
        — 
      

    


  
I compared with the original site and I found, that the overflow property must be the cause.
Please recheck if it's still invalid, because the site worked before and I didn't changed anything.

  

  



        Attachment #8342398 -
        Attachment is obsolete: true
Flags: needinfo?(dholbert)

    
    

    
  

      
      
      
      

        Attached file
          
        testcase2 (obsolete) (deleted)
        — 
      

    


  
bug fixed

  

  



        Attachment #8342426 -
        Attachment is obsolete: true

    
    

    
  
In those testcases, the overflow:hidden on <main> isn't important, just the fact that <main> exists and is only as tall as the <div> it contains, thus correctly preventing sticky positioning from moving the <div>.

  

  



    
    

    
  

      
      
      
      

        Attached file
          
        testcase2 (deleted)
        — 
      

    


  

  

  



        Attachment #8342431 -
        Attachment is obsolete: true

    
    

    
  
Okay, I'm not sure why that one doesn't work (in either Aurora or Nightly, so it doesn't look brand-new).

  

  



    
    

    
  
If this testcase now is similar to the original site, I'm sure that it worked before 2013-12-02. I can't explain why, because I didn't' change anything in my profile or in the code. I coded it on Sunday and next day (I downloaded newest versions of Firefox) it didn't work anymore. And it seems the only thing that changed here was bug 931460.

  

  



    
    

    
  
Can you please find a regression range with mozregression[1] and maybe bisect it to get a clearer picture here?

[1] http://mozilla.github.io/mozregression/

  

  


Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(dholbert) → needinfo?(sjw)
Resolution: INVALID → ---

    
    

    
  
testcase2 doesn't depend on flexbox; if I remove the "display: flex" from <main> and <div>, the behavior remains the same (there's no stickiness happening).

I'm pretty sure what's happening there is that <main> is getting recognized as the scroll container, since it has "overflow" set (making it scrollable). So <div> is sticky, *with respect to scrolling in <main>* -- _not_ with respect to scrolling the body.

And as it happens, <main> doesn't get scrolled, because its contents easily fit inside of it (and also because there's no user-exposed way to scroll it).

So, I'm still pretty sure this is invalid, but if the behavior really did change (and we can determine what changed it, per comment 10), I suppose it'd be interesting to know why.

  

  



    
    

    
  
(I confirmed my suspicion in Comment 11 by tweaking <main>'s style to replace "overflow: hidden" with "overflow: scroll", and tweaking its height to be shorter than its contents (e.g. 150px) so that it's actually usefully-scrollable. Then, if you scroll <main> itself, you'll see that its contents don't change position.)

  

  



    
    

    
  
(In reply to Florian Bender from comment #10)
> Can you please find a regression range with mozregression[1] and maybe
> bisect it to get a clearer picture here?
> 
> [1] http://mozilla.github.io/mozregression/

I couldn't find a regression since https://hg.mozilla.org/mozilla-central/pushloghtml?tochange=e9337081c744

So it may be a fault of mine and it was not working before and I didn't noticed, or I did it wrong with mozregression. =/

  

  


Flags: needinfo?(sjw)

    
    

    
  
OK. Sticking with the 'invalid' label, then, per comment 3 / comment 11 / comment 12.

If you end up finding that the behavior changed in a way that broke this at some point, feel free to post more info and/or reopen.

  

  


Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → INVALID

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: