Closed Bug 1532444 Opened 1 year ago Closed 1 year ago

Dynamic change to marker style causes it to continuously repaint forever


(Core :: SVG, defect)

Not set



Tracking Status
firefox-esr60 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- fixed


(Reporter: dholbert, Assigned: longsonr)



(Keywords: regression, Whiteboard: [qf:p3:resource])


(3 files, 1 obsolete file)

Attached file testcase 1

0. Make sure you have web render disabled and paint flashing enabled:

  gfx.webrender.all = false
  nglayout.debug.paint_flashing = true
  1. View attached testcase.

One second after loading, when the text becomes bold, its background-color should flash once (indicating a single repaint).

When the text becomes bold, the background starts flashing continuously and never stops. It looks like we get into a never-ending "invalidate/repaint/invalidate/etc." loop.

Whiteboard: [qf] → [qf:p3:resource]

Is the <text> element required? If so did this work properly before Cam's <text> element rewrite?

Hmm, good thoughts!

  • the text element does indeed seem to be required
  • I can't reproduce flashing in a build from 2013-01-01

So this is a regression from some point (perhaps Cam's text rewrite).

Keywords: regression

Also: in a build from 2015-07-11, the text continuously repaints even before I've made a dynamic style change.

Here's the fix range, for where we went from immediate continuous-repaints (comment 4) to only repainting once a dynamic style change has been made (the current behavior):

For text we'll end up in SVGTextFrame::ScheduleReflowSVGNonDisplayText somehow we're triggering that again and again I assume.

The original regression range here (going from "no continuous paint flashing" to "immediate & continuous flashing" per comment 4, for text) was:

Looks like probably a regression from bug 1090936.

Depends on: 1090936

I suspect the SVGTextFrame::ReflowSVGNonDisplayText change was wrong and should be reverted then.

Attached patch strawman.txt (obsolete) — Splinter Review

Revert the invalid part of bug 1090936 as SVGTextFrame::ReflowSVGNonDisplayText is already asynchronous
as callers invoke it via SVGTextFrame::ScheduleReflowSVGNonDisplayText

I checked that we get one update on the style change and no continuous paint flashing now.

Attachment #9048690 - Attachment is obsolete: true

Thanks for the help figuring it out Daniel, comment 2 and the bug causing the regression really pinpointed the error.

Assignee: nobody → longsonr
Pushed by
Go back to doing synchronous invalidation in ReflowSVGNonDisplayText as its invoked by ScheduleReflowSVGNonDisplayText so is already asynchronous r=dholbert
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

It would've been nice to land a test for this...

Any ideas how one would write such a test?

Flags: needinfo?(emilio)

We should be able to use nsIDOMWindowUtils.checkAndClearPaintedState() to ensure that we don't paint the frame in two consecutive frames without any change.

Flags: needinfo?(emilio)
Blocks: 1090936
No longer depends on: 1090936
Flags: in-testsuite?
QA Whiteboard: [qa-67b-p2]
You need to log in before you can comment on or make changes to this bug.