Removing display:none <svg:marker> sometimes doesn't repaint

RESOLVED WORKSFORME

Status

()

Core
SVG
--
minor
RESOLVED WORKSFORME
9 years ago
6 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {testcase})

Trunk
x86
Mac OS X
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Created attachment 359185 [details]
testcase

The testcase should appear green, but sometimes it appears red until I resize the Firefox window.
I suspect that what is happening is this.

We trigger a refresh when the content changes i.e. the display attribute is set.
The refresh triggers an async repaint and the race is on...

On the near side we have frame creation
On the stand side we have the async repaint.

The winner is indicated by red or green.

Not sure what the answer is though.
(In reply to comment #1)
> We trigger a refresh when the content changes i.e. the display attribute is
> set.

You mean through a mutation observer? The style can change without the style attribute changing, so it's worse than that.
Created attachment 359391 [details]
testcase #2

This testcase doesn't have a race, it just displays incorrectly.
One option would be to set up some kind of hook so that when we construct frames for an element that we want to have nsSVGRenderingObservers on, we notify potential observers.

But ... according to the SVG spec, should we actually be displaying a marker even if it's display:none? I have a sinking feeling that we maybe we should.
(In reply to comment #4)
> 
> But ... according to the SVG spec, should we actually be displaying a marker
> even if it's display:none? I have a sinking feeling that we maybe we should.

indeed we're sunk by http://www.w3.org/TR/SVG11/painting.html#MarkerElement final paragraph and tracked by bug 376027
So we just need to fix 376027, however hard that may be, and that will fix this bug.
These testcases now display consistently correctly. Now sure why but marker implementation changed a lot around firefox 9.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.