Closed
Bug 397362
Opened 17 years ago
Closed 17 years ago
stroke-dasharray in svg draws lines to origin
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: teun, Unassigned)
References
Details
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
When using a stroke-dasharray attribute on a <polyline/> element, there is a rendering bug where lines are drawn to the origin.
<svg xmlns="http://www.w3.org/2000/svg" xlink="http://www.w3.org/1999/xlink" viewBox="0 0 3000 2000" height="100%" width="100%" baseProfile="full" version="1.1" style="margin: 0; width: 100%; height: 100%;">
<polyline stroke-dasharray="10,10,10" stroke-width="10" fill="none" stroke="rgb(237, 206, 106)"
points="440,1430 447,1430 453,1430 460,1430 467,1430 473,1430 480,1430 487,1430 493,1430 500,1430 507,1430
513,1430 520,1430 527,1430 533,1430 540,1430 547,1430 553,1430 560,1430 566,1430 573,1430 580,1430 586,1430
593,1430 600,1430 606,1430 613,1430 620,1430 626,1430 633,1430 640,1430 646,1430 653,1430 660,1430 666,1430
673,1430 680,1430 686,1430 693,1430 700,1430 706,1430 713,1430 720,1430 726,1430 733,1430 740,1430 746,1430
2131,1430 2137,1430 2144,1430 2151,1430 2157,1430 2164,1430 2171,1430 2177,1430 2184,1430 2191,1430
2197,1430 2204,1430 2211,1430 2217,1430 2224,1430 2231,1430 2237,1430 2244,1430 2251,1430 2257,1430
2264,1430 2271,1430 2277,1430 2284,1430 2291,1430 2297,1430 2304,1430 2311,1430 2317,1430 2324,1430
2330,1430 2337,1430 2344,1430 2350,1430 2357,1430 2364,1430 2370,1430 2377,1430 2384,1430 2390,1430
2397,1430 2404,1430 2410,1430 2417,1430 2424,1430 2430,1430 2437,1430 2444,1430 2450,1430 2457,1430
2464,1430 2470,1430 2477,1430 2484,1430 2490,1430 2497,1430 2504,1430 2510,1430 2517,1430 2524,1430
2530,1430 2537,1430 2543,1430 2550,1430 2557,1430 2563,1430 2570,1430 2577,1430 2583,1430 2590,1430
2597,1430 2603,1430 2610,1430 2617,1430 2623,1430 2630,1430 2637,1430 2643,1430 2650,1430 2657,1430
2663,1430 2670,1430 2677,1430 2683,1430 2690,1430 2697,1430 2703,1430 2710,1430 2717,1430 2723,1430
2730,1430 2737,1430 2743,1430 2750,1430 2756,1430 2763,1430 2770,1430 2776,1430 2783,1430 2790,1430
2796,1430 2803,1430 2810,1430 2816,1430 2823,1430 2830,1430 2836,1430 2843,1430 2850,1430 2856,1430
2863,1430"/>
</svg>
Reproducible: Always
Steps to Reproduce:
Create a file like in the example above.
Save it as test.svg
Open it in Firefox
Actual Results:
Lines are drawn to the origin (top left corner)
Expected Results:
No lines to the origin
Reporter | ||
Comment 1•17 years ago
|
||
Comment 2•17 years ago
|
||
Looks fixed on trunk (=coming Firefox 3.0). Trunk builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Updated•17 years ago
|
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Comment 3•17 years ago
|
||
Seems to work on the trunk.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Comment 4•17 years ago
|
||
Expected:
A rectangle with a dash array used as stroke is displayed.
Observed:
The stroke used in the left and bottom sides of the rectangle is erroneous and incoherent: or no stroke at all is displayed or a solid stroke is used. Can this be a Windows-specific issue?
Note:
The symptom shows depending on the view port used. One may change the "viewport" attribute directly, but it's simpler to resize the window several times until the two different behaviors are obtained.
Version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021804 Minefield/3.0b4pre
Comment 5•17 years ago
|
||
Expected:
A rectangle with a red dash array is displayed with a blinking black-stroked rectangle partially above.
Observed:
The partial area covered by the black-stroked rectangle is filled with red when the first blink occurs. Can this be a Windows-specific issue?
Note:
The symptom shows depending on the view port used. One may change the "viewport" attribute directly, but it's simpler to resize the window several times until the two different behaviors are obtained.
Version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021804 Minefield/3.0b4pre
Comment 6•17 years ago
|
||
I've experienced this issue (again?) in nightly builds.
The issue can be seen in the original attachment ("Svg file that shows the bug in the polyline with stroke-dasharray"), although two new test cases were reduced and attached. One for static content, other for partial redraw operations.
Can this be a Windows-specific (cairo) issue?
Version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021804 Minefield/3.0b4pre
Flags: blocking1.9?
Comment 7•17 years ago
|
||
Seems like another regression from the cairo update.
I can't reproduce the original problem in the original testcase where lines were being drawn from every dash of the horizontal line to the top left corner of the client area. However, I can reproduce the new problems you're reporting with the two new testcases when I resize the window vertically only. For the testcase with the red stroked rectangle, I only get the red filled area bug if I vertically resize the window until the left and bottom edges of the black rectangle show.
Comment 8•17 years ago
|
||
I meant I only get the red filled area bug if I vertically resize the window until the left and bottom edges of the *red* rectangle show.
Comment 9•17 years ago
|
||
I think this is a different issue to that originally reported and should probably be raised in a new bug to avoid confusion.
Comment 10•17 years ago
|
||
Well the new tests seem to have been fixed now by bug 418353, so no point I guess.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: blocking1.9?
Comment 11•17 years ago
|
||
@Jonathan Watt
«I can't reproduce the original problem in the original testcase where lines were being drawn from every dash of the horizontal line to the top left corner of the client area.»
«Well the new tests seem to have been fixed now by bug 418353, so no point I
guess.»
I'll try to attach a screen shot which shows the symptom on the original attachment *before* trying to update to the latest nightly build. This way it will be documented to ease comparison for possible regressions in the future.
«For the testcase with the red stroked rectangle, I only get the red filled area bug if I vertically resize the window until the left and bottom edges of the black rectangle show.»
That is correct. Both attachments are dependent on view port size (stated in the attachment's comments, although not very visible).
Comment 12•17 years ago
|
||
(In reply to comment #11)
> I'll try to attach a screen shot which shows the symptom on the original
> attachment *before* trying to update to the latest nightly build. This way it
> will be documented to ease comparison for possible regressions in the future.
Not been able to reproduce the symptom on the original attachment (using build 2008021804). The only reason that occurs to me is that maybe I messed up and was using Firefox 2 (to fetch some bookmark) when opening that specific attachment... :-(
The two new test cases, although SVG-based, suggest a close relation with bug 417543.
Version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021804 Minefield/3.0b4pre
Comment 13•17 years ago
|
||
(In reply to comment #12)
> Not been able to reproduce the symptom on the original attachment (using build
> 2008021804). The only reason that occurs to me is that maybe I messed up and
> was using Firefox 2 (to fetch some bookmark) when opening that specific
> attachment... :-(
Possibly. It's easy to do. :-)
> The two new test cases, although SVG-based, suggest a close relation with
> bug 417543.
Yes, I think it was the same root cause.
Please note that the latest nightly build may not have the cairo fix in it yet. You may need to wait 24 hours for the next build.
Comment 14•17 years ago
|
||
99% of the issue seems fixed now. A possible regression, slightly hard to reproduce, was isolated (and attached).
Steps to Reproduce:
1. Open attachment the dynamic test case attached [1].
2. Resize the window several times.
Actual result:
Contents are resized. In some view port sizes (usually, larger ones), a red line appears.
Expected result:
Contents are (simply) resized.
Additional notes:
IMHO this issue may be located in the partial redraw mechanism forced by the blinking rectangle, as I haven't been able to reproduce it using the static attachment [2].
Attached file is an animated PNG so one should be able to see the blinking behavior (when using Firefox 3+ and/or Opera 9.5+).
On the other hand, the blink shown an apparent bug in Firefox implementation of APNG (bottom portion of the window used in screen shot blinks). This seems a new and separate issue and was filed as bug 418848.
Version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022104 Minefield/3.0b4pre
[1] https://bugzilla.mozilla.org/attachment.cgi?id=304254
[2] https://bugzilla.mozilla.org/attachment.cgi?id=304253
Comment 15•17 years ago
|
||
(In reply to comment #14)
Please create a new bugzilla bug for this.
Comment 16•17 years ago
|
||
Comment 17•17 years ago
|
||
Thanks Helder.
Updated•17 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•