Closed Bug 1281068 Opened 4 years ago Closed 4 years ago
Applying blur filter hides/moves elements that are position fixed, can also effect page's scroll position
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 Steps to reproduce: Go to www.rehearsal.com, scroll down a bit, click "Demo" -- Header disappears then re-appears on modal close. Go to www.blackbirdgo.com/menu#/, scroll down a bit, click "Sign up" -- Header disappears. On modal close, the header re-appears and the page's scroll position snaps to top. Actual results: Applying a blur filter to a page's main container hides elements that are position fixed. When the blur is removed, the elements snap back into place. Sometimes the page's scroll position resets to top. Expected results: Applying a blur should not hide/move elements that are position fixed. Those elements should be unaffected. Page's scroll position should also not change. Repeat the "What did you do" steps (box 1) in Chrome and you can see how it should work. This was not a problem until very recently. I believe the issue started occurring in v47.0.
I'm not able to join the website your provided, server issue?
Hello Reporter, I tried duplicating this issue with exact steps you have mentioned in this bug and I see same behavior on Chrome and Firefox on both the sites. I couldn't reproduce any scrolling issue too. I tested on following versions Version 47.0 Build ID 20160604131506 User Agent Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0 Version 50.0a1 Build ID 20160622030210 User Agent Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
@Kanchan Thank you for trying. It is weird that you could not reproduce. I am going to record my screen and post a link to the video.
Link to video: http://szakara.com/misc/ff-vs-chrome.mp4
Hello Reporter, Thanks for sharing the recording which clearly shows the bug. This is to confirm that I am able to reproduce this bug. Hunted down and found Last good revision: 611823f79eb548fd9d14c7c73483c030561c98f5 First bad revision: c88f281bf19ae0a9b115a7a127e62758555e02f3 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=611823f79eb548fd9d14c7c73483c030561c98f5&tochange=c88f281bf19ae0a9b115a7a127e62758555e02f3
Component: Untriaged → Layout
Product: Firefox → Core
Flags: needinfo?(szakara) → needinfo?(dbaron)
STR: 1) Open https://www.blackbirdgo.com/menu#/ 2) Scroll down the webpage 3) Click on the "log in" field
This is the behavior required by the spec, and implemented initially in bug 1125767 and correctly for dynamic changes in bug 1187851.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Based on comment #9, mark as wont fix for all branches.
So... just never going fix this?
As Firefox follows the spec here, no. It's the correct behavior now.
Can you (or anyone) provide a link to the part of the spec that Mozilla is following here? It is super weird that unfixing fixed elements on blur is the correct behavior.
It looks like we're following a resolution from the FXTF (which manages this spec), referenced in bug 1125767 comment 5. The quote from the minutes there is: > RESOLUTION: non-none values of filter induce a containing block for all positioned descendants > <scribe> ACTION: Erik to make non-none values of filter induce a containing block > for all positioned descendants [recorded in http://www.w3.org/2015/02/10-fx-minutes.html#action02] https://www.w3.org/2015/02/10-fx-minutes.html#action02 I don't immediately see this change reflected in the spec ( https://drafts.fxtf.org/filters/ ), so it's possible that the action/resolution was accidentally never acted upon.
It looks like dbaron noticed this discrepancy as well, and filed a spec bug on getting the afore-mentioned FXTF resolution into the spec: https://github.com/w3c/fxtf-drafts/issues/11 So, once that git issue is closed, the spec will be up-to-date with what the FXTF has resolved on (and what we've implemented), at least on this point.
3 years ago
See Also: → 1311070
2 years ago
Duplicate of bug: 1226095
You need to log in before you can comment on or make changes to this bug.