Summary: | REGRESSION (r219193): Custom data attribute objects are lost randomly, maybe due to garbage collection | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | fabian.schwarzkopf | ||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED DUPLICATE | ||||||
Severity: | Normal | CC: | dino, sabouhallawa, schlm3, seb.p.mueller, svillar, webkit-bug-importer, zimmermann | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Safari Technology Preview | ||||||
Hardware: | Mac | ||||||
OS: | Unspecified | ||||||
URL: | http://live.yworks.com/yfiles-for-html/2.0/view/grapheditor/index.html | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=172545 | ||||||
Attachments: |
|
Description
fabian.schwarzkopf
2017-08-01 08:00:43 PDT
Does this also break the actual product, or just the demos? (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. Would you be able to come up with a reduced test case? 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? This test case is perfect. I'm close to finding the regression. And of course it is already in the title :) (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. Sergio, do you plan to tackle this regression? (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. I think that the new symptom is worse than the one fixed originally, so rolling back seems like the next step then. (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. Rolling back. *** This bug has been marked as a duplicate of bug 175398 *** > 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?
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. 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). 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. Same issue on macOS 10 with Safari 11. It looks fine in Safari Tech Preview 40, though. We have been hit by this bug last week. Very inconvenient and sad that iOS11 has been released with that known bug. 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. |