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
,
Mar 10 2016
,
Mar 11 2016
,
Mar 11 2016
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?
,
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.
,
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?
,
Mar 15 2017
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
,
Mar 15 2017
,
Mar 15 2017
,
Mar 15 2017
Marking as having a dependency on https://bugs.chromium.org/p/chromium/issues/detail?id=382170
,
Mar 15 2017
There should be no dependency between these two (issue 382170 is for SVG-in-<img>, while this is related to external <use> references.)
,
Apr 16 2018
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
,
Apr 16 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by meh...@chromium.org
, Mar 9 2016