You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: Rogue Line in scatterplot in some environments #558
That commit was part of a branch that was removing the remaining nested <svg> tags for compatibility with Adobe Illustrator. It required changing from a <svg> tag that was constrained by it's viewBox to a <g> tag that has an associated clip - it's most likely that the clip is being miscalculated in the scenario provided.
Could you share the data and layout you have used for this example so we could reproduce? I can't seem to make a (not) working example myself.
It's possible, but unlikely. Are you on the most recent release for your local environment? It looks as if the clip is not being properly set on the plot <g> element. Which browser are you using? I didn't see any significant inconsistencies when implementing the clip, but it's very possible I may have overlooked something - any extra info will be helpful to debug.
seems like it might be a clip issue:
when this gets called during relayout, I get negative x values for the points that render to the left of the axes:
what attributes on objects / functions should i be looking at pertaining to the 'clip'
I see this, but not sure if it's what i want.
Sorry for the radio silence... just not much I know how to do.
Where would I look for to debug the clip / what sort of values would I expect to give me radically 'off the charts' lines?
We're pinned to 1.9.0 indefinitely until we figure this out or it magically goes away. :(
Here's the problematic block which I believe was put in the support Angular 1 (cc @alexcjohnson ) a few years ago.
Obviously, this solution isn't working for all environments. So, instead of determining whether or not to prefix the clip paths URLs with window.location.href based on <base>, maybe we should make this a config option e.g. clipPathPrefix?
However this code brings a big limitation as mentioned in the comment the chart is not portable no more.
I just wonder why the document location is used when a base element is found and there is no comment on this specific line of code which cause the limitation.
(the base href value is "/" in most of Angular2 applications)
Activity
mdtusz commentedon May 23, 2016
That commit was part of a branch that was removing the remaining nested
<svg>tags for compatibility with Adobe Illustrator. It required changing from a<svg>tag that was constrained by it'sviewBoxto a<g>tag that has an associated clip - it's most likely that the clip is being miscalculated in the scenario provided.Could you share the data and layout you have used for this example so we could reproduce? I can't seem to make a (not) working example myself.
alexander-alvarez commentedon May 23, 2016
so trying to reproduce it in a fresh environment and no luck...
http://codepen.io/anon/pen/reXdVV
After the
Plotly.relayout()it seems things go AWOL in our environmentwould styling/position not captured here affect this?
mdtusz commentedon May 23, 2016
It's possible, but unlikely. Are you on the most recent release for your local environment? It looks as if the clip is not being properly set on the plot
<g>element. Which browser are you using? I didn't see any significant inconsistencies when implementing the clip, but it's very possible I may have overlooked something - any extra info will be helpful to debug.alexander-alvarez commentedon May 23, 2016
Running: Chrome 49.0.2623.110 under Linux and Mac
seems like it might be a clip issue:
when this gets called during relayout, I get negative x values for the points that render to the left of the axes:
what attributes on objects / functions should i be looking at pertaining to the 'clip'
I see this, but not sure if it's what i want.
plotly.js/src/plot_api/plot_api.js
Line 2916 in 716a621
mdtusz commentedon May 24, 2016
That is the correct plot clip - unfortunately they're a bit tricky to debug because you can't just add a border to them 😛
I still haven't been able to reproduce this, so any more information you come across will be helpful.
alexander-alvarez commentedon Jun 2, 2016
Sorry for the radio silence... just not much I know how to do.
Where would I look for to debug the clip / what sort of values would I expect to give me radically 'off the charts' lines?
We're pinned to 1.9.0 indefinitely until we figure this out or it magically goes away. :(
[-]Bug: Rogue Line in scatterplot[/-][+]Bug: Rogue Line in scatterplot in some environments[/+]dev-oups commentedon Nov 24, 2016
I am facing this problem using Plotly in an Angular 2 application.
I am using the # anchor in the URL to manage client routing.
The element g with class="plot" has a wrong clip-path property.
It contains the full page URL: "url(http://127.0.0.1:43422/#/workspace/studies#clip8a724bxyplot)".
Replacing it with "url(#clip8a724bxyplot)" will solve the problem.
Please let me know if it can be fixed, thanks.
etpinard commentedon Nov 24, 2016
Interesting. Can you share a reproducible example in a codepen / jsFiddle / jsBin to help us debug?
dev-oups commentedon Nov 24, 2016
Here it is:
http://plnkr.co/edit/KzOqZY2MYBPX7MmHIZ6V?p=preview
etpinard commentedon Nov 24, 2016
@dev-oups Thanks very much for that example!
Here's the problematic block which I believe was put in the support Angular 1 (cc @alexcjohnson ) a few years ago.
Obviously, this solution isn't working for all environments. So, instead of determining whether or not to prefix the clip paths URLs with
window.location.hrefbased on<base>, maybe we should make this a config option e.g.clipPathPrefix?etpinard commentedon Nov 24, 2016
Oh I think I know what's the problem. For your page
which contains a
#, which (must, right?) conflicts with the#that precedes the clip path id.So perhaps replacing
window.location.hrefwithwould do the trick.
Copying a few colleagues that might know more about this subject @bpostlethwaite @mdtusz @monfera @rreusser @n-riesco
etpinard commentedon Nov 29, 2016
A potential fix has been merged in #1203 hence closing this issue.
Once plotly.js
v1.21.0is out, please let us know if it indeed resolved your issues.dev-oups commentedon Nov 29, 2016
OK thanks.
However this code brings a big limitation as mentioned in the comment the chart is not portable no more.
I just wonder why the document location is used when a base element is found and there is no comment on this specific line of code which cause the limitation.
(the base href value is "/" in most of Angular2 applications)