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.

Categories

(Core :: Layout, defect)

47 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1226095
Tracking Status
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- wontfix

People

(Reporter: szakara, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

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
Flags: needinfo?(szakara)
@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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
STR:
1) Open https://www.blackbirdgo.com/menu#/
2) Scroll down the webpage
3) Click on the "log in" field
This is not something that will be included in a dot release.
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
Flags: needinfo?(dbaron)
Resolution: --- → INVALID
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.
No longer blocks: 1125767, 1187851
Resolution: INVALID → DUPLICATE
Duplicate of bug: 1226095
You need to log in before you can comment on or make changes to this bug.