New issue
Advanced search Search tips

Issue 732919 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 258029
Owner: ----
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-06-26
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Chrome 59 doesn't render svg visualizations correctly when hidden behind Bootstrap tabs?

Reported by crowdbou...@gmail.com, Jun 13 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce the problem:
1. Create d3.js visualizations hidden behind Bootstrap tabs
2. Click tab to reveal visualizations
3. 

What is the expected behavior?
My apologies in advance, I don't have an easy way to reproduce this. I'm hoping someone can help me determine if this is expected behavior due to a recent change in Chrome or if this is a legitimate bug.

I have d3.js visualizations hidden in Bootstrap tabs. When a new Bootstrap tab is clicked, the visualizations are shown. This works great in Chrome 58 and earlier. It also works in Safari. Now with Chrome 59, the d3.js charts don't render properly when a new Bootstrap tab is selected. 

The problem is similar to this issue described in this Stack Overflow issue:
https://stackoverflow.com/questions/21563609/nvd3-charts-not-rendering-correctly-in-hidden-tab

However the solutions suggested there do not work anymore. The 'resize' event doesn't fix the issue.

I tested with the most recent versions of d3.js and Bootstrap without luck.

What went wrong?
It renders the visualization in the selected tab without the background colors for some reason. However the visualizations in the default selected tab are working properly. Again, this was working in Chrome 58 and earlier.

Did this work before? Yes 58

Chrome version: 59.0.3071.86  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

Thank you!
 
Cc: pbomm...@chromium.org
Components: -Blink Blink>SVG
Labels: pre-stable-59.0.3071.86 M-59
 crowdbounties@ if possible can you please provide test page for further triage.
Components: Blink>Paint>Invalidation
Labels: Needs-Feedback
NextAction: 2017-06-26
I appreciate the challenges of reproducing this. Can you point us to a GitHub project or a staging server or something where we can look at the page that is trying to render.

To be clear, the issue is missing background colors, right? What type of element is the background color associated with?
Thank you for the replies and I apologize for the lack of detail and reproduction. Yes, it's missing the gradient background coloring in the hidden tabs. I think I narrowed it down to the following code. Note this is coffeescript.

				gradient = svg.append('svg:defs')
					.append('svg:linearGradient')
					.attr('id', 'gradient')
					.attr('x1', x1)
					.attr('y1', '0%')
					.attr('x2', x2)
					.attr('y2', '0%')
					.attr('spreadMethod', 'pad')

				gradient.append('svg:stop')
					.attr('offset', '0%')
					.attr('stop-color', color_1)
					.attr 'stop-opacity', .8

				gradient.append('svg:stop')
					.attr('offset',  "#{mean_percent}%")
					.attr('stop-color', color_2)
					.attr 'stop-opacity', 1

				gradient.append('svg:stop')
					.attr('offset', '100%')
					.attr('stop-color', color_3)
					.attr('stop-opacity', .8)

				svg.append('svg:rect')
					.attr("rx", 4)
					.attr("ry", 4)
					.attr('y', bar_y)
					.attr('x', bar_x)
					.attr('width', bar_w)
					.attr('height', bar_h)
					.style 'fill', 'url(benchmarking#gradient)'
					.style("stroke", bar_outline_color)
					.style("stroke-width", 1)

This code works in the default displayed Bootstrap tab, but not in the hidden content starting in Chrome 59.

When I remove this code and change the background colors to solid coloring, it works as expected in all tabs.

Are there any known changes that may account for this?

Thank you!
Project Member

Comment 5 by sheriffbot@chromium.org, Jun 13 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pbommana@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Narrowing it down further, it has something to do with this property:

     .style 'fill', 'url(benchmarking#gradient)'

This is no longer able to call the 'gradient' ID for the visualizations in the hidden Bootstrap tabs starting in Chrome 59. The default tab is working though.

I tried only using the ID tag:

     .style 'fill', 'url(#gradient)'

And using the full path to test:

     .style 'fill', 'url(http://localhost:3000/benchmarking#gradient)'

But the result was the same.



I successfully reproduced the issue on a test page:

https://codepen.io/anon/pen/OgXevy

The second tab displays the visualization in Chrome <= 58, but not Chrome 59.

Please advise. Thanks!


Comment 8 by f...@opera.com, Jun 14 2017

Components: -Blink>Paint>Invalidation
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Bisected to:

https://chromium.googlesource.com/chromium/src/+log/65dff8b6da7b33d422b5e02356e58254fded9006..e8e3eea556d5713612f304b2c35e193658fa4f90

Very likely 533d683571c860e69bb3ecaf6214c5ceed25a808, or rather made visible by it , since we'd now correctly pick the first <linearGradient> with the 'gradient' id. Making this essentially a dupe of issue 258029 or  issue 448169  (or both.)

A workaround for this is to reference the gradient in the non-display-none subtree (by means of unique id.)
Labels: PaintTeamTriaged-20170613 BugSource-User
fs@, am I right then in concluding that this is a problem with d3 and Bootstrap, or the site, rather than a failure on our part?

Comment 10 by f...@opera.com, Jun 14 2017

Not really, it's an old bug of ours that now gained more visibility. It does seem quite common to end up in situations like this when using frameworks like these (probably because you tend to generate multiple independent fragments, and lacking a simple mechanism for avoiding duplication of the same paint server[s].)
> A workaround for this is to reference the gradient in the non-display-none subtree (by means of unique id.)

This is a bit over my head. Can someone help me understand how to implement the workaround within the context of my example here?
https://codepen.io/anon/pen/OgXevy

Thank you

Comment 12 by f...@opera.com, Jun 14 2017

https://codepen.io/anon/pen/BZLxeJ is a simple example of the workaround applied to the original pen.
Thank you fs@! I appreciate you help and patience with a novice like me.

Do you accept cryptocurrency tips? I'd be happy to support you. 

Comment 14 by f...@opera.com, Jun 14 2017

You're welcome. I do not accept tips, but thank you for your support nonetheless!

Comment 15 by benha...@gmail.com, Jun 21 2017

I have a similar issue, but don't know if I should file the bug separately?
https://jsfiddle.net/benhahne/031edweb/

I wasn't able to determine whether there is a standard for redefining the <defs> with the same id's :-/

Comment 16 by f...@opera.com, Jun 21 2017

Mergedinto: 258029
Status: Duplicate (was: Untriaged)
c#15, yes that's the same issue. (And thanks for reminding me that I should dupe this...)
The NextAction date has arrived: 2017-06-26

Sign in to add a comment