Closed
Bug 467472
Opened 17 years ago
Closed 17 years ago
Inconsistent painting with <svg:marker>, dynamic overflow:visible
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(3 files, 2 obsolete files)
The testcase has a seemingly random amount of blue in it. This seems to be a painting issue, since it can change when I switch windows and can even depend on which tab I switched from.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Based on layout/reftests/svg/dynamic-marker-01.svg
Comment 3•17 years ago
|
||
I think the check in for bug 462369 fixed this.
Reporter | ||
Comment 4•17 years ago
|
||
Yes, looks like this is fixed.
Reporter | ||
Comment 5•17 years ago
|
||
I'm seeing this bug again.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 6•17 years ago
|
||
I think bug 472135 fixed this.
Comment 7•17 years ago
|
||
Just checked in the debugger and it does use the new refresh code path.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Comment 8•16 years ago
|
||
Attachment #384942 -
Flags: review?
Updated•16 years ago
|
Attachment #384942 -
Flags: review? → review?(dbaron)
Comment 9•16 years ago
|
||
Please don't add files to the bugs directory we're trying to get rid of it. Instead add them to the parent directory with a file name that indicates what you are testing. In this case perhaps dynamic-marker-02.svg would be appropriate.
Did you test that the reftest failed in a build that had the bug, and passes in one without it?
Comment 11•16 years ago
|
||
Moved out of the bugs folder and named as dynamic-marker-02, as suggested.
The test SVG reproduces the problem on this build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/12/2008-12-01-02-mozilla-central/
To repro it on that build you have to manually add a line of code:
setTimeout(boom, 2000);
as I don't believe that build supports the "MozReftestInvalidate" event, and so the test cannot be run as-is in reftest.
Test passes as-is on current trunk builds.
Attachment #384942 -
Attachment is obsolete: true
Attachment #387668 -
Flags: review?(dbaron)
Attachment #384942 -
Flags: review?(dbaron)
Attachment #387668 -
Flags: review?(dbaron) → review?(longsonr)
Comment 12•16 years ago
|
||
Comment on attachment 387668 [details] [diff] [review]
invalidate reftest
You should do what the other reftests do i.e. something along the lines of
document.addEventListener("MozReftestInvalidate", boom, false);
// in case we're not gecko
setTimeout(boom, 5000);
That way it will work on abuild/browser that does not support MozReftestInvalidate will still be OK.
Attachment #387668 -
Flags: review?(longsonr) → review-
Comment 13•16 years ago
|
||
Thanks for the suggestion; I have added the setTimeout() to the test so that it works on browsers that don't support MozReftestInvalidate.
Attachment #387895 -
Flags: review?
Updated•16 years ago
|
Attachment #387668 -
Attachment is obsolete: true
Updated•16 years ago
|
Attachment #387895 -
Flags: review? → review+
Updated•16 years ago
|
Keywords: checkin-needed
Updated•16 years ago
|
Attachment #387895 -
Attachment description: invalidate reftest → invalidate reftest (checkin-needed)
Comment 14•16 years ago
|
||
Pushed test from comment 13 as http://hg.mozilla.org/mozilla-central/rev/6beb76d1c2d8
Keywords: checkin-needed
Updated•16 years ago
|
Attachment #387895 -
Attachment description: invalidate reftest (checkin-needed) → invalidate reftest
You need to log in
before you can comment on or make changes to this bug.
Description
•