Issue metadata
Sign in to add a comment
|
SVG textPath that works in 48 does not work in 49
Reported by
undefine...@gmail.com,
Mar 25 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.108 Safari/537.36 Example URL: https://ember-twiddle.com/fbf7831e0fc1eca012ae Steps to reproduce the problem: 1. The textPath element does not show up properly in the example provided when open in Chrome 49. It does, however, work in 48. What is the expected behavior? What went wrong? The text and textPath elements of the SVG are in the wrong place and have a size of 0 (for both height and width). The provided example works just fine in Chrome 48. I also tried it in Firefox 45.0.1, where it is also broken. If I copy the DOM element for the SVG and paste it into a separate HTML file (with the proper styles added), everything works fine. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? Yes 48 Does this work in other browsers? No Firefox 45.0.1 Chrome version: 49.0.2623.108 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0
,
Mar 25 2016
,
Mar 25 2016
Because this agrees with firefox, I suspect this is just how it works. I have to admit I'm not sure what the bug is though. Is it possible to make a jsbin/jsfiddle version that shows the incorrect behavior?
,
Mar 25 2016
Ember-twiddle does not work in IE or Safari. But when I locally use that example in IE and Safari, it works fine. As I said, it also worked fine in Chrome up until a few days/weeks ago when I was on 48. In 49 it doesn't work. I'll see if I can drum up a jsfiddle that doesn't work.
,
Mar 28 2016
Maybe we could try a bisect to see if we'll be any the wiser.
,
Mar 28 2016
,
Mar 28 2016
Oh, I see srcdoc... https://jsfiddle.net/j8ppcwp1/2/ seems to repro the problem. Ref issue 473547 (https://bugs.chromium.org/p/chromium/issues/detail?id=473547#c6)
,
Mar 28 2016
If I use the ember code by itself, not in ember-twiddle, as far as I know there is no srcdoc yet I still have the problem.
,
Mar 29 2016
Bisect info: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/38b2f1369ee256717e05cc2f9c8ccbb449e6bdf2..6967287223ccbe29db1454e6ace0d412524aac25 suspecting https://chromium.googlesource.com/chromium/src/+/d97f56157c1d119d3a0dda5d5d341e099f7f2b26 shanmuga.m@, Could you please check the above issue & help us in finding an owner it its not yours. Good Build: 49.0.2566.0 Bad Build: 49.0.2567.0 able to reproduce the issue on Win7, Mac OS X 10.11.3, Ubuntu 14.04 using Chrome Dev #51.0.2687.0, Canary 51.0.2692.0, Beta #50.0.2661.49 and in stable #49.0.2623.110 using https://jsfiddle.net/j8ppcwp1/2/
,
Mar 29 2016
@nyerramilli, Thank you for notifying me!! I will take care of this issue..
,
Mar 29 2016
,
Mar 29 2016
,
Mar 29 2016
@shanmuga.m: I don't think there's any need to rush here - if the "not in ember-twiddle" case turns out to be the same as the "in ember-twiddle" case, then this is a dupe of the bug mentioned above ( issue 473547 ), or possibly issue 470608 . A issue very similar to the former was recently brought up in the CSS WG, so we should wait and see what that ends up with and then implement it.
,
Mar 29 2016
@fs, Thank you for the update. Anyway I have just made a patch to fix this issue. (not fixing 473547) https://codereview.chromium.org/1842643003/
,
Mar 29 2016
I did some more testing on my specific issue. In my actual application, removing the <base> tag fixes the problem. Ember uses the <base> tag. So I guess this is a duplicate of 470608. That said, it sounds like there was another issue related to the srcdoc that was found in the process.
,
Mar 29 2016
The issue with iframe @srcdoc is the same - in that case the base URL is the one of document that hosts the iframe. Duping to issue 470608 sounds reasonable.
,
Apr 1 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by undefine...@gmail.com
, Mar 25 2016