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.
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.
*** 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:
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.
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.