Closed
Bug 1482727
Opened 6 years ago
Closed 6 years ago
Video inside an element with css filter blur does not update if not moving the mouse
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox-esr60 | --- | unaffected |
firefox61 | --- | disabled |
firefox62 | --- | disabled |
firefox63 | --- | disabled |
firefox64 | --- | fixed |
People
(Reporter: rformato, Assigned: mattwoodrow)
References
(Blocks 1 open bug, )
Details
(Keywords: nightly-community, regression)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0 Build ID: 20180812100044 Steps to reproduce: OSX 10.13.6 navigate to https://mixthebody.britishcouncil.org/ and open the menu clicking on the top right icon. Actual results: The video is not more updated unless you move the mouse Expected results: The video should be updated normally even not moving the mouse
Reporter | ||
Updated•6 years ago
|
Summary: Video inside an element with css filter blur does not update is not moving the mouse → Video inside an element with css filter blur does not update if not moving the mouse
Reporter | ||
Comment 1•6 years ago
|
||
I just realized this happens when gfx.webrender.all is set to true
Updated•6 years ago
|
Blocks: webrender-site-issues
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Graphics: WebRender
Ever confirmed: true
Keywords: nightly-community
OS: Unspecified → All
Product: Firefox → Core
Comment 2•6 years ago
|
||
mozregression --good 2018-04-01 --bad 2018-08-12 --pref gfx.webrender.all:true -a https://mixthebody.britishcouncil.org/ > 11:25.15 INFO: Last good revision: 4816cf388e2620e7c4c71b7882adfa9d1198e643 > 11:25.15 INFO: First bad revision: c0ad7aed2ab0b9cb145a09723d01c5398802f785 > 11:25.15 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4816cf388e2620e7c4c71b7882adfa9d1198e643&tochange=c0ad7aed2ab0b9cb145a09723d01c5398802f785 2018-04-17 > c0ad7aed2ab0 Kartikaya Gupta — Bug 1453688 - Update reftest annotations for WR PR 2662. r=jrmuizel > 7dce432f2403 Kartikaya Gupta — Bug 1453688 - Update reftest annotations for WR PR 2642. r=jrmuizel > 94f0b582e4a6 Kartikaya Gupta — Bug 1453688 - Update webrender to commit 5bcb7f46c6931633fd20813c46cd69af164effe7. r=jrmuizel https://github.com/servo/webrender/compare/6f997974cec5772b1797725f4a7942d742e7d7ff...5bcb7f46c6931633fd20813c46cd69af164effe7
Blocks: 1453688
Has Regression Range: --- → yes
status-firefox61:
--- → disabled
status-firefox62:
--- → disabled
status-firefox63:
--- → disabled
status-firefox-esr52:
--- → unaffected
status-firefox-esr60:
--- → unaffected
Keywords: regression
Updated•6 years ago
|
Blocks: stage-wr-trains
Priority: -- → P2
Assignee | ||
Comment 3•6 years ago
|
||
Looks like this is a regression from https://github.com/servo/webrender/commit/d48fe709a0a852d8e47cffc1486de0c88326374e I guess we should avoid caching Pictures that are updated external? Or invalidate their cache if we get an external update. The initial patch suggested that the cache would only persist across async scrolls, but I guess external updates for a new video frame count as the same thing here. Any ideas on the best fix Glenn?
Flags: needinfo?(gwatson)
Comment 4•6 years ago
|
||
During the culling pass, we recurse into all primitives inside each picture primitive. It should be easy to set a flag in the PictureState structure here when we encounter an image that references an external (native) image. When that flag is set, the picture preparation code can choose not to cache that picture. It may make sense to make it a general flag that any primitive can set in order to disable caching of that picture, which may be useful in the future for other primitives.
Flags: needinfo?(gwatson)
Updated•6 years ago
|
Assignee: nobody → matt.woodrow
See Also: → https://github.com/servo/webrender/pull/3050
Assignee | ||
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
status-firefox64:
--- → fixed
Target Milestone: --- → mozilla64
Updated•6 years ago
|
Flags: needinfo?(jan)
Comment 5•6 years ago
|
||
This fix is not platform agnostic. Win10 with ANGLE is fixed. Still reproducible with Debian Testing (and Win10 without ANGLE).
Flags: needinfo?(jan)
You need to log in
before you can comment on or make changes to this bug.
Description
•