New issue
Advanced search Search tips

Issue 593261 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Issue with rendering external source SVG elements while script tag present

Reported by byuu...@gmail.com, Mar 9 2016

Issue description

Chrome Version       : 48.0.2564.116
OS Version: OS X 10.11.3
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

What steps will reproduce the problem?
1. Download resources and put them on some server. I test on Apache/2.4.16 (Unix) on OSX.
2. Hit Cmd+R (refresh) on keyboard until you notice first two svg icons missing.

What is the expected result?
All svg elements should be always displayed after refresh.

What happens instead of that?
External svg is not rendered correctly in some cases. In seems that putting script tag after svg tag will make sometime svg tags that were placed before that script tag disappear.

Few things I noticed:

1. Hard refresh (Cmd+Shift+R) will make all icons always appear.
2. When issue happens there two http requests are made for external svg resource. Check "chrome_network.jpg" for more details.
3. When issue happens there is no present shadow DOM in two not rendered svg tags. Check "chrome_elements.jpg" for more details.
4. Removing all script tags with "console.log(...);" code will make svg elements appear correctly.
5. Putting test.svg and/or app.css content inside of index.html file resolves issue.

Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36



 
index.html
1.1 KB View Download
app.css
42 bytes View Download
test.svg
559 bytes Download
chrome_elements.jpg
348 KB View Download
chrome_network.jpg
150 KB View Download
Components: Blink
Components: -Blink Blink>SVG
Labels: -OS-Mac OS-All
Status: Untriaged (was: Unconfirmed)

Comment 3 by f...@opera.com, Mar 11 2016

Status: Available (was: Untriaged)

Comment 4 by f...@opera.com, Mar 11 2016

Cc: japhet@chromium.org
Components: Blink>Loader
Looks like this is related to Resource revalidation.

The missing icons first initiate a load and get a resource and a notifyFinished(). (I think this is from preloading.) When the (first of the) rest of the icons show up, we decide to revalidate the resource and hence call Resource::load() again. This means the Resource flips back to "is loading" which in turn mean that when we try to expand the <use>s again (all of them), we observe the resource as loading.
Because the initial two resources have already received notifyFinished() they won't get a notification when the revalidation completes, and only the "later" uses get invalidated and rebuilt properly...

So, when revalidating, should finished clients be moved back to the "unfinished" clients list, or should the client itself be tracking this?

japhet?

Comment 5 by japhet@chromium.org, Mar 14 2016

Aaah, that's tricky. I think the client should probably be tracking this. We don't currently have a mechanism to demote finish clients back to unfinished. Also, resources that stream data break in fantastic ways if they receive callbacks for both the original data and the revalidated data, so we shouldn't revert to unfinished in the general case. I guess we could have a way for SVGUseElement to manually request that its clients be made unfinished, but it doesn't have a good way to detect that a revalidation started, so it's probably better to just have it track the needed state itself.

Comment 6 by f...@opera.com, Mar 14 2016

I guess tracking that client-side wouldn't be too hard - we just need a way to tell when revalidation fails I guess? 
Project Member

Comment 7 by sheriffbot@chromium.org, Mar 15 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 8 by f...@opera.com, Mar 15 2017

Status: Available (was: Untriaged)
Labels: -Hotlist-Recharge-Cold PaintTeamRetriaged-20170315
Blockedon: 382170
Marking as having a dependency on https://bugs.chromium.org/p/chromium/issues/detail?id=382170

Comment 11 by f...@opera.com, Mar 15 2017

Blockedon: -382170
There should be no dependency between these two (issue 382170 is for SVG-in-<img>, while this is related to external <use> references.)
Project Member

Comment 12 by sheriffbot@chromium.org, Apr 16 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 13 by f...@opera.com, Apr 16 2018

Status: Available (was: Untriaged)

Sign in to add a comment