question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Bug?] Strange clip-path problem

See original GitHub issue

Hi everyone.

So I have this strange problem, where the clip-path in the SVG is wrong due to addition of the location to the clip-path url.

I have the exact same HTML offline, where when you generate the SVG from a file:// location you get something like:

<defs id="defs-fac894">
        <g class="clips">
            <clipPath id="clipfac894xyplot" class="plotclip"><rect width="518" height="350"/></clipPath>
            ...

together with:

<g class="cartesianlayer">
        <g class="subplot xy">
            ...
            <g class="plot" transform="translate(42, 50)" clip-path="url(#clipfac894xyplot)">
            ...

But when you do the same online you get:

<defs id="defs-6f068e">
        <g class="clips">
            <clipPath id="clip6f068exyplot" class="plotclip"><rect width="518" height="350"/></clipPath>
            ...

together with:

<g class="cartesianlayer">
        <g class="subplot xy">
             ...
            <g class="plot" transform="translate(42, 50)" clip-path="url(https://www.mydomain.com#clip6f068exyplot)">
             ...

If you use .downloadImage on the original state of each plot, both images are identical. If you do this with a zoomed state, where you pass the x.range and y.range to the layout for .downloadImage the resulting image isn’t clipped correctly in the online version.

This is an image that results of the first code (used offline with file://-URL) after zooming: svg_offline.zip

This is an image that results of the latter code (used online with https://-URL) after zooming: svg_online.zip

When you change

<g class="plot" transform="translate(42, 50)" clip-path="url(https://www.mydomain.com#clip6f068exyplot)">

to

<g class="plot" transform="translate(42, 50)" clip-path="url(#clip6f068exyplot)">

(in other words: remove the location part from the url) you get the desired image.

This was tested with the current Firefox 63 as well as Firefox 52 ESR and current Microsoft Edge.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:14 (6 by maintainers)

github_iconTop GitHub Comments

2reactions
Braintelligencecommented, Nov 19, 2018

@alexcjohnson actually I have the same problem when saving as PNG. I could just trace the cause by looking at the SVG.

2reactions
alexcjohnsoncommented, Nov 19, 2018

Maybe it’s safe leaving it out in Plotly.downloadImage then?

Yes, that’s the goal (at least when downloading as SVG, I suspect we still need it to download as PNG etc). The difficulty is the way we currently stash baseUrl in the singleton drawing module (at least we do stash it https://github.com/plotly/plotly.js/commit/5887104139256934bbf554bf62685fbec62585d2 🎉). We could instead stash it with the plot (in _context or _fullLayout or something), but that would require altering every call to setClipUrl to have gd as an argument.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Clip-path on Chrome leaves a strange line on the edge
I believe this works because it puts the element into a sort of "3d" rendering mode which does not seem to have the...
Read more >
clipPath Android Chrome Flicker-Bug - GSAP - GreenSock
The issue occurs when I start tweening x or y WHILE CLIP-PATH is still tweening. As soon as I get rid of x...
Read more >
svg renders with artifacts on clippath with large dimension
I originally encountered this problem with smaller dimensions and a scale transform but reduced it to this case. I tried specifying a viewport ......
Read more >
Unfortunately, clip-path: path() is Still a No-Go - CSS-Tricks
Save for the odd case where the element we want to clip actually has a fixed pixel size, the path() function is completely...
Read more >
postscript, Strange bug (?) with strokepath
was not a problem with the printer or our interface). The problem turned out to be a call to 'strokepath'. The application created...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found