RESOLVED DUPLICATE of bug 175398 Bug 175023
REGRESSION (r219193): Custom data attribute objects are lost randomly, maybe due to garbage collection
https://bugs.webkit.org/show_bug.cgi?id=175023
Summary REGRESSION (r219193): Custom data attribute objects are lost randomly, maybe ...
fabian.schwarzkopf
Reported 2017-08-01 08:00:43 PDT
Created attachment 316854 [details] Reproduction of lost data attributes on SVG We noticed in the Safari Technology Preview Release 36 (macOS Sierra, 10.12.6) that the demos of our product did not work as expected anymore (e.g. see http://live.yworks.com/yfiles-for-html/2.0/view/grapheditor/index.html). The transform that is applied to the SVG is often not applied at all or it works for some time but then gets broken randomly (try zooming or select all with CMD+A and then zoom). For optimization reasons, we cache the transformable on the SVG element (as custom attribute) and subsequently only update the cached transformable. It seems that sometimes this attribute is lost or is not the same anymore as the one that was attached initially. Please find attached to this bug report is a small repro to demonstrate the issue. Steps to reproduce: * Open the index.html * Start zooming in and out with the mousewheel * At one time the cached instance is not the same anymore and changing its values won't transform the SVG (this is indicated by the green bar turning to red once the issue triggers) We were able to trigger the problem more often when creating more dummy nodes in the code (see index.html). Supposedly, this triggers the garbage collector which then breaks the cached transformable. Note: Comparing the repro with the current Chrome implementation shows, that the instance seems to change too, but the transform can still be changed by manipulating the attached object.
Attachments
Reproduction of lost data attributes on SVG (2.76 KB, text/html)
2017-08-01 08:00 PDT, fabian.schwarzkopf
no flags
Radar WebKit Bug Importer
Comment 1 2017-08-01 17:17:50 PDT
Alexey Proskuryakov
Comment 2 2017-08-01 17:21:17 PDT
Does this also break the actual product, or just the demos?
fabian.schwarzkopf
Comment 3 2017-08-02 01:07:05 PDT
(In reply to Alexey Proskuryakov from comment #2) > Does this also break the actual product, or just the demos? The 'product' is an API / library while the demos are demo implementation of it. Thus you can say, the demos are the product in that sense. When it fails in the demos, it will fail for our customers in their products, too.
Sergio Villar Senin
Comment 4 2017-08-02 02:13:04 PDT
Would you be able to come up with a reduced test case?
fabian.schwarzkopf
Comment 5 2017-08-02 02:19:45 PDT
The attachment (Reproduction of lost data attributes on SVG) resembles the issue in a reduced test case. Or is an even more reduced test case needed?
Dean Jackson
Comment 6 2017-08-02 06:59:57 PDT
This test case is perfect. I'm close to finding the regression.
Dean Jackson
Comment 7 2017-08-02 08:05:09 PDT
And of course it is already in the title :)
Sergio Villar Senin
Comment 8 2017-08-02 10:12:15 PDT
(In reply to fabian.schwarzkopf from comment #5) > The attachment (Reproduction of lost data attributes on SVG) resembles the > issue in a reduced test case. Or is an even more reduced test case needed? Oh right that's perfectly fine, I had just looked at the link in the first comment.
Alexey Proskuryakov
Comment 9 2017-08-08 22:15:24 PDT
Sergio, do you plan to tackle this regression?
Sergio Villar Senin
Comment 10 2017-08-09 01:15:03 PDT
(In reply to Alexey Proskuryakov from comment #9) > Sergio, do you plan to tackle this regression? I have it in my TODO list but I don't have much time ATM. I'm fine with somebody else taking over. Otherwise I'll try to fix it as soon as possible.
Alexey Proskuryakov
Comment 11 2017-08-09 12:40:47 PDT
I think that the new symptom is worse than the one fixed originally, so rolling back seems like the next step then.
Dean Jackson
Comment 12 2017-08-09 12:55:39 PDT
(In reply to Alexey Proskuryakov from comment #11) > I think that the new symptom is worse than the one fixed originally, so > rolling back seems like the next step then. I agree.
Alexey Proskuryakov
Comment 13 2017-08-09 15:08:11 PDT
Rolling back. *** This bug has been marked as a duplicate of bug 175398 ***
Alexey Proskuryakov
Comment 14 2017-08-09 15:11:19 PDT
> When it fails in the demos, it will fail for our customers in their products, too. Could you please list your customers' products, or characterize user impact in some other way?
Sebastian Müller
Comment 15 2017-08-10 00:29:42 PDT
I am CTO of yWorks, who produces the API where the bug was found and reported. Here is an excerpt of our customer list: https://www.yworks.com/company/references Our product "yFiles for HTML" is affected, which is a library. Also our new end user application (which uses that library) "yEd Live" is affected: https://www.yworks.com/products/yed-live https://www.yworks.com/products/yfiles-for-html The bug makes the product unusable on the preview version of the affected UAs. The applications behave like an image viewer where you disable zooming and panning and interaction becomes impossible. Otherwise this is a very rich graph editing application and with the bug in place it becomes a bad viewer application, only. Most of the deployments of our products at our customers are in closed intranets or at least inaccessible from the public web, and for many customers we may not disclose usage of our products in their deployments. About half of the customers for which there are logos here https://www.yworks.com/#references however would be affected by that bug and anyone with an IT background will easily recognize at least 60% of them, I would say. For example this application here would be affected, too, from what I can tell just "by looking at the JavaScript" of the running app: https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-topology-overview We *could* implement a performance costly workaround, however there's hundreds of deployments on websites that would have to update and probably several thousands of devices which have the software built-in into their management backends which cannot be updated as easily (think complex switches and appliances with built-in web servers and management software). If you require more details, I can disclose some of them in a private email. Please get in contact with our company via the homepage in that case. I, too, would agree that a rollback would be the best solution for now.
Sergio Villar Senin
Comment 16 2017-08-29 02:35:14 PDT
This should be fixed in master now. Hopefully you could test it in the next technology preview (not sure about when Safari is going to ship this change).
fabian.schwarzkopf
Comment 17 2017-09-29 08:37:13 PDT
Did the fix not make it into the release of iOS 11.0.1 and its Safari 11? I can see the same rendering issues that we have reported here in Safari 11 on our iOS11 ipad. We also received several bug reports by our customers which have rendering issues on iOS11.
fabian.schwarzkopf
Comment 18 2017-09-29 08:44:19 PDT
Same issue on macOS 10 with Safari 11. It looks fine in Safari Tech Preview 40, though.
Markus Schlegel
Comment 19 2017-10-02 13:02:38 PDT
We have been hit by this bug last week. Very inconvenient and sad that iOS11 has been released with that known bug.
Sebastian Müller
Comment 20 2017-10-04 03:27:04 PDT
Note: the broken demo in the report has been modified in the meantime so that it does not exhibit the erroneous behavior anymore. The attached testcase is still valid (and broken for current Safari releases) and should be used instead for testing.
Note You need to log in before you can comment on or make changes to this bug.