Bug: Rogue Line in scatterplot in some environments

[alexander-alvarez]

it seems there's a regression:

v1.9.0:

v.1.10.0-v1.11.0

using git bisect I narrowed it down to: b6d9930

not sure what information I can provide to better help out, but just let me know so I can help out.

[mdtusz]

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.

[alexander-alvarez]

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 environment

would styling/position not captured here affect this?

[mdtusz]

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]

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

var clips = fullLayout._defs.selectAll('g.clips'),

[mdtusz]

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]

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. :(

[dev-oups]

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]

I am facing this problem using Plotly in an Angular 2 application.

Interesting. Can you share a reproducible example in a codepen / jsFiddle / jsBin to help us debug?

[dev-oups]

Here it is:

• open a hero details view
• move on the x axis to see traces moving outside the plot

http://plnkr.co/edit/KzOqZY2MYBPX7MmHIZ6V?p=preview

[etpinard]

@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.href based on <base>, maybe we should make this a config option e.g. clipPathPrefix?