Closed Bug 822014 Opened 12 years ago Closed 12 years ago

The behavior of clip-path on outer-<svg>s that have a border changed in Firefox 17

Categories

(Core :: SVG, defect)

17 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: richard.berg, Assigned: jwatt)

References

Details

(Keywords: regression, testcase)

Attachments

(6 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: (Figures attached in file.) An SVG graphic that rendered correctly in v 16.0.2 now is clipped on the right side and bottom in version 17.0.1. Thus the entire graphic is not visible. Actual results: The release notes for v 17 indicate a developer change for SVG was incorporated. Considering that the graphic was displayed correctly in v 16, the questions is whether the developer change created the problem. The SVG code has not changed. The incorrect rendering is also apparent in v 18 beta 4. Expected results: I would have expected the graphics to have been rendered the same in both versions.
I should add that this graphic renders correctly in both IE8 & IE9, and the most recent versions of Google Chrome.
Can you share a URL for the SVG file in question? (or attach it to the bug) There's not much that can be done without an actual testcase that triggers the bug. Having said that, this is likely a duplicate of bug 818841.
Flags: needinfo?(richard.berg)
Please read the readme file first, then have at the others. Thanks.
Flags: needinfo?(richard.berg)
In Opera the grey border goes round the whole black rectangle. That's the issue right?
I don't use Opera. In Google Chrome and IE, yes the border goes around the whole image. The border is actually part of the image. Note, too, that the v17 image has lost 5-10% at the right side and the bottom. The v16 image is the way this graphic should look.
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/6dae57cd2f85 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120720145842 Bad: http://hg.mozilla.org/mozilla-central/rev/045c11dd41a6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120720205642 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6dae57cd2f85&tochange=045c11dd41a6 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/a746aaa32b22 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120720114508 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/62f19ed60528 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120720115241 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a746aaa32b22&tochange=62f19ed60528 Regressed by : Bug 614732
Blocks: 614732
Status: UNCONFIRMED → NEW
Ever confirmed: true
I tried to help by commenting out various parts of my .asp script, to see if not executing some specific drawing command had any effect. I commented out, separately, the "area" statements drawing the shaded blue background. No impact. Then the "grid" that puts the grid on the graphic. No change. Then the "path" that draws the green profile line. No change. Then all the "path" commands that draw the curved lines in the graphic - again, no change. Then the "polygon," followed by the "area" masks, the "axes" and the "text" labels. Eliminating these in turn had no effect. If I commented out the "SVG.locked = true" statement just below the <div..., I could then scroll the mouse thumbwheel to reduce the graphic and see that the graphic was all there. Taken altogether, this seems to me that the issue is in the interpretation of the <div...> itself at the top, or from the Firebug dump, in the <svg>, <defs> or <clipPath> parts. I'm not the expert here, and I'm not at all familiar with Firefox other than as a user. I thought this information might be useful to you.
I did one more thing: in my .asp file, I commented out all the code between the opening <div ...> and the closing </div> at the bottom. When I ran this in FF 17, the same problem remains. In FF16 there is no problem. What I've attached are two images for the graphic Canvas, one rendered in FF v16.0.2 and the other in v17.0.01, plus the pertinent Firebug sections for each. The Firebug lists are extremely brief, as you would expect since there's no real content, and they are identical except for the "id".
If you could the testcase once you've removed all extraneous detail that would be useful.
Posting the testcase The relevant original .asp code with all the detail removed is this: <div class='SVGgraph' style='background-color:#000030;' options="width:570,height:360,scales:[-30,360,-10,90], border:'grey solid 4px',pan:false,zoom:false"></div> ------------------------------------ Firebug view from FF17.0.1 rendering: <div class="SVGgraph" options="width:570,height:360,scales:[-30,360,-10,90], border:'grey solid 4px'" style="background-color: rgb(0, 0, 48); position: relative; width: 570px; height: 360px;"> <svg id="XwYSgVfPZIqjdtDA" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" baseProfile="full" style="border:grey solid 4px" clip-path="url(#XwYSgVfPZIqjdtDAClipPath)" width="570" height="360"> <defs id="XwYSgVfPZIqjdtDA_Defs"> <clipPath id="XwYSgVfPZIqjdtDAClipPath"> <path d="M0,0 570,0 570,360 0,360"> </clipPath> </defs> <g id="XwYSgVfPZIqjdtDA_Canvas"> </svg> </div> Firebug view from FF16.0.2 rendering: <div class="SVGgraph" options="width:570,height:360,scales:[-30,360,-10,90], border:'grey solid 4px'" style="background-color: rgb(0, 0, 48); position: relative; width: 570px; height: 360px;"> <svg id="KVQRgqfEGBKYzCnv" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" baseProfile="full" style="border:grey solid 4px" clip-path="url(#KVQRgqfEGBKYzCnvClipPath)" width="570" height="360"> <defs id="KVQRgqfEGBKYzCnv_Defs"> <clipPath id="KVQRgqfEGBKYzCnvClipPath"> <path d="M0,0 570,0 570,360 0,360"> </clipPath> </defs> <g id="KVQRgqfEGBKYzCnv_Canvas"> </svg> </div> These are identical except for the "id".
Richard: Here's one observation and recommendation that may help you. You are using clip-path on an outer-<svg> element. This is not interoperable between different browsers, and I strongly recommend that you do not put clip-paths on outer-<svg> at this time.
It's worth mentioning that clip-path clipping of outer-<svg> changed in Firefox 16 (bug 773450), although the regression range identified by Alice says that's not directly the cause of this bug.
There's also a bug where clipPath clipping doesn't apply correctly to non-SVG and outer-<svg> elements in some cases: bug 804003.
Richard: so if I remove the clip-path from the <svg> element in the "reporters testcase as attachment", I get exactly the same rendering of that testcase in Firefox 17 as in Firefox 16. If removing clip-path from the outer-<svg> elements in your app doesn't fix things for you, then we need a new testcase to be able to progress here. Please let us know either way.
Flags: needinfo?(richard.berg)
Jonathan, Okay. I opened my app live using FF17. The graphic is clipped as I've noted above. Here is the relevant Firebug code. It's the same as before. (I removed the "pan" and "zoom" attributes which had no affect anyway): <div class="SVGgraph" options="width:570,height:360,scales:[-30,360,-10,90], border:'grey solid 4px'" style="background-color: rgb(0, 0, 48); position: relative; width: 570px; height: 360px;"> <svg id="mwCHzfxLSyimnXKB" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" baseProfile="full" style="border:grey solid 4px" clip-path="url(#mwCHzfxLSyimnXKBClipPath)" width="570" height="360"> Then, in Firebug, I Deleted Attribute "clip-path". The resultant code is this: <div class="SVGgraph" options="width:570,height:360,scales:[-30,360,-10,90], border:'grey solid 4px'" style="background-color: rgb(0, 0, 48); position: relative; width: 570px; height: 360px;"> <svg id="HUCRNikGkOyeROVl" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" baseProfile="full" style="border:grey solid 4px" width="570" height="360"> Now the graphic is no longer clipped in FF17 and is rendered as I would expect.
Flags: needinfo?(richard.berg)
(In reply to Jonathan Watt [:jwatt] from comment #12) > Richard: Here's one observation and recommendation that may help you. You > are using clip-path on an outer-<svg> element. This is not interoperable > between different browsers, and I strongly recommend that you do not put > clip-paths on outer-<svg> at this time. Jonathan: There's basically nothing I can do or know how to do here. I am just a user of a plugin that was written by someone else, so I do not know the details of how the plugin relates to producing "standard" SVG, nor how "clip-path" is placed where it is. But, I WILL pass your recommendation along to the author who will hopefully understand just what you are saying and be able to act on it. Could it be that this is where the problem lies, and it's not an issue with FF17? Thanks for your help!
(In reply to richard.berg from comment #17) > But, I WILL pass your recommendation > along to the author who will hopefully understand just what you are saying That'd be great, thank you. > Could it be that this is where the problem lies, > and it's not an issue with FF17? It seems that bug 614732 has changed the behavior of clip-path clipping on outer-<svg> elements. I'm not sure if that change is desirable or not just yet, but content on the Web should definitely stay away from using clip-path on outer-<svg> elements if the content's author wants their content to be interoperable between the various browsers.
Jonathan: I was able scan through the mathSVG plugin code and locate the statement that places the 'clip-path="url...' attribute in the outer-<svg>. I removed it, and when I reloaded the plugin and then reran the .asp file in my environment, FF17 rendered the entire graphic perfectly. So I think this is indeed a fix I can make permanent on my end to eliminate this problem. This is especially good in view of your comment about using alternative browsers. However, I am waiting for the author of the plugin to get back to me about this change. I don't know if there are unintended consequences within the plugin by doing what I've done. None are obvious to me, but as I said, I didn't write the plugin. When I have an answer, I'll pass it along. The fix on my end resolves the bug for me.
I've did some experiments with clip-path on outer-<svg>, and what changed is that we now apply clip-path to the CSS border box instead of the content box. Furthermore we now clip the border and the content, not just the content. This makes our treatment of clip-path on outer-<svg> consistent with how we treat clip-path on other CSS layout non-SVG elements such as <div>. The two testcases I just attached demonstrate this. I think this is a desirable change, and as such I'll close this bug as invalid. All the same, thanks a lot for the bug report, Richard. It's good to know that we changed this behavior, even if it was unintentionally.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Summary: SVG rendering error in version 17 is okay in version 16 → The behavior of clip-path on outer-<svg>s that have a border changed in Firefox 17
(In reply to Jonathan Watt [:jwatt] from comment #22) > I've did some experiments with clip-path on outer-<svg>, and what changed is > that we now apply clip-path to the CSS border box instead of the content > box. Furthermore we now clip the border and the content, not just the > content. This makes our treatment of clip-path on outer-<svg> consistent > with how we treat clip-path on other CSS layout non-SVG elements such as > <div>. The two testcases I just attached demonstrate this. I think this is a > desirable change, and as such I'll close this bug as invalid. All the same, > thanks a lot for the bug report, Richard. It's good to know that we changed > this behavior, even if it was unintentionally. Your welcome. Last question: Does this mean that it will now be okay to leave the clip-path on an outer-<svg>?
The short answer is no, per the last chunk of comment 18 -- that all still applies. (The only clarification to that chunk is that jwatt has now investigated and determined that the behavior-change was a desirable one -- but it's still a behavior-change, so any content that relies on the old behavior will be broken.)
Thanks, all. I enjoyed the interaction with you all, and I learned a few new things from you, too, which I appreciate. I'm glad this was not a problem for you after all.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: