Closed Bug 397362 Opened 17 years ago Closed 17 years ago

stroke-dasharray in svg draws lines to origin

Categories

(Core :: SVG, defect)

x86
Windows XP
defect
Not set
normal

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
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Seems to work on the trunk.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
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
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
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?
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.
Blocks: 416018
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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.
I think this is a different issue to that originally reported and should probably be raised in a new bug to avoid confusion.
Depends on: 418353
Well the new tests seem to have been fixed now by bug 418353, so no point I guess.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Flags: blocking1.9?
@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).
(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
(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.
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
(In reply to comment #14) Please create a new bugzilla bug for this.
(In reply to comment #15) > Please create a new bugzilla bug for this. Done- filed as bug 418901.
Thanks Helder.
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: