372574 - SVG patterns are not live to color changes

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Load one of the testcases.

Expected: green squares.

Result: red squares (at least some of the time).

(Split from bug 327764 comment 10.)

Comment 1

[Jesse Ruderman]

Attachment: testcase 1: change color onload (always fails)

Comment 2

[Jesse Ruderman]

Attachment: testcase 2: change color 100ms after onload (often fails)

Comment 3

[Jesse Ruderman]

With testcase 2, there also seems to be a slight shift in the position of the squares (at least when the squares remain red).

Comment 4

[Jesse Ruderman]

I'm curious why the setTimeout makes a difference.  When do I need to use setTimeout when making reftests for other SVG bugs?  For example, if I were to make a reftest for the removeChild part of bug 327764, should I make two versions of the reftest, one with setTimeout and one without?

Comment 5

[Jesse Ruderman]

In testcase 2, the shift is present even when the squares do turn green.  The most obvious way to see this is to press Cmd++ (text zoom) after loading it.  This seems to be a painting problem, so I'm not sure reftest can test it.

Comment 6

[Jesse Ruderman]

Is there a way to force SVG to lay out and maybe paint, similar to the "document.body.offsetHeight;" trick for HTML, or am I stuck using timeouts?

Comment 7

[Jesse Ruderman]

WFM, Mac trunk debug.