Closed Bug 1482403 Opened Last year Closed Last year

DigitalOcean map doesn't paint properly


(Core :: Web Painting, defect, P1)

63 Branch



Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 + wontfix
firefox64 --- fixed
firefox65 --- verified


(Reporter: jrmuizel, Assigned: miko)


(Blocks 1 open bug, )


(Keywords: regression)


(3 files)

Sometimes some of the blured shapes seem clipped. I suspect this is a regression from bug 1480620 or one of the other blob changes.
The map I mean is at the bottom of
Greenland: It also seems to happen with Basic compositing, but not with Chrome Dev (HW accel on/off). I suspect layout.display-list.retain.
Priority: -- → P3
mozregression --good 2018-07-01 --bad 2018-08-10 --pref gfx.webrender.all:true -a
> 7:35.14 INFO: Last good revision: 03ecdc85a12613b5fb79805c32a9896395351415
> 7:35.14 INFO: First bad revision: ae6e737276854a376177f2a64c15e9172e01ab8a
> 7:35.14 INFO: Pushlog:

> ae6e73727685	Matt Woodrow — Bug 1475413 - Prefer using old items for uninvalidated frames during display list merging. r=miko

Also happens without WebRender and can be fixed with layout.display-list.retain;false.
Blocks: 1475413
No longer blocks: stage-wr-trains
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Graphics: WebRender → Layout: Web Painting
Flags: needinfo?(matt.woodrow)
OS: Unspecified → All
Priority: P3 → --
This regression affects 63 and has no owner nor priority set, could this bug be prioritized? Thanks
Any chance you can take a look at this Miko?

The fix is either to add a new type to ShouldUseNewItem, or to mark the frame as modified when the property changes.

Should be able to look at the display list when it's broken and try spot which item is rendering wrong.
Flags: needinfo?(matt.woodrow) → needinfo?(mikokm)
Priority: -- → P2
Assignee: nobody → mikokm
Flags: needinfo?(mikokm)
Attached file
Minified testcase
Priority: P2 → P1
Previously we did not always create nsDisplayOpacity, when creating nsDisplayFilter or nsDisplayMask for frames with opacity. Because this decision was made during DL building, and could change without frame invalidation, the retained display list merging would sometimes get confused when the container item type changed.
This patch always wraps frames with visual opacity in nsDisplayOpacity, unless the frame is an SVG frame that supports optimizing stroke/fill opacity, or if the frame is an SVGImage frame.
For most cases, the performance penalty should be minimal. The common case is that nsDisplayOpacity passes opacity handling to nsDisplayMasksAndClipPaths or nsDisplayFilters though opacity flattening mechanics.
Miko, do you have a status update on this issue? thanks
Flags: needinfo?(mikokm)
(In reply to Pascal Chevrel:pascalc from comment #10)
> Miko, do you have a status update on this issue? thanks

The patch is ready and waiting for a review.
Flags: needinfo?(mikokm)
Pushed by
Always create nsDisplayOpacity for filters and masks when there is visual opacity r=jwatt
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Is it possible to write a test for this?
Flags: needinfo?(mikokm)
Flags: in-testsuite?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> Is it possible to write a test for this?

The original "simplified" testcase was very complex (due to 300KB of minified JS applying unpredictable style changes), but I will look into it.
Flags: needinfo?(mikokm)
Duplicate of this bug: 1503601
Bug 1503601 has a much simpler test-case that was fixed by this patch, any chance we could land something based on that?
Flags: needinfo?(mikokm)
Thank you Emilio, I used that testcase to create a reftest.
Flags: needinfo?(mikokm)
[Tracking Requested - why for this release]: We're getting quite a few dupes of this bug, would be nice if it could be fixed if there's any 63 ridealong.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)
> [Tracking Requested - why for this release]: We're getting quite a few dupes
> of this bug, would be nice if it could be fixed if there's any 63 ridealong.

This has only recently landed and was not uplifted to beta yet so that will probably not make it into the dot release for Desktop planned for this week. I am tracking it though in case we have another dot release before we ship 64.
Duplicate of this bug: 1504175
Wontfix for 63 as we are unlikely to have another dot release before 64 ships 3 weeks from now.
Flags: qe-verify+

I reproduced this issue using Fx 63.0a1, build ID: 20180810220115, on Windows 10 x64 and Ubuntu 18.04 x64.

I can confirm this issue is fixed, I verified using Fx 65.0b9, build ID: 20190107180200, on Windows 10 x64 and Ubuntu 18.04 LTS.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.