Hang when changing HTMLObjectElement.data |
||||
Issue descriptionFrom https://bugs.chromium.org/p/chromium/issues/detail?id=461670#c9: "I'm seeing something much worse than "no effect": when changing the data source (setting .data = x or using .setAttribute("data", x) on an object containing an SVG, Chrome (57 stable & 59.0.3045.0 canary tested) completely hangs for me, with high CPU consumption. Probably related: this more general bug about problems with changing `data` on objects of various types: https://bugs.chromium.org/p/chromium/issues/detail?id=589109#c11 I've only tested with local files so far, so it is possible that there is some extra security complication causing infinite loops."
,
Mar 20 2017
Thanks for looking into this. I did some more testing myself. It *seems* to be something specific to SVG views, and specifically with changing the data attribute from an SVG to a view of the same SVG. Whenever I do that, the SVG disappears (even though the view works fine on its own). However, it only hangs sometimes. It may be related to file URLs versus local host/HTTP URLs, or it may be related to running it from script versus using the console, I'm not 100% sure. I will try to narrow it down a bit more & report back here when I have clear steps to reproduce.
,
Mar 22 2017
Changing the navigation target in the above to "resources/left.svg#svgView(viewBox(0,0,50,50))" I am able to reproduce disappearing behavior described in c#2. From file: and http: schemes. I also notice that the size negotiation seem to fail (the resulting <object> is 300x150.)
,
Mar 23 2017
Looked a bit at what's going on here, and it seems we get into a (re)load loop triggered by the lazy-reattach on the 'data' change (which detaches the 'Widget') and kept alive by layout of the LayoutEmbeddedObject (which schedules the part for update, and the loop is a fact because the 'Widget' is never reset...) Presumably what we're missing is something that resets the 'Widget' in this particular case (fragment navigations), and the constant reloading surely does not help with that =). This probably also only affects SVGs embedded like this because of issue 442939 . (But fixing that would have no effect here because size renegotiation would still need to take place.)
,
Mar 28 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
,
Mar 29 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by f...@opera.com
, Mar 20 2017I tested with this (w/ and w/o 'type'): <!DOCTYPE html> <object data="resources/left.svg"></object> <script> window.onload = function() { setTimeout(function() { document.querySelector('object').data = "resources/right.svg"; }, 100); }; </script> ('left.svg' and 'right.svg' are simple 100x100 SVGs with a single <text> element.)