New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 598035 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 470608
Owner:
Last visit > 30 days ago
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



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 description

UserAgent: 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
 
Here is a JS Fiddle (https://jsfiddle.net/j8ppcwp1/1/) that just has the SVG that shows the proper behavior.

Comment 2 by rsesek@chromium.org, Mar 25 2016

Components: Blink>SVG
Labels: -Type-Compat Type-Bug-Regression

Comment 3 by pdr@chromium.org, 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?
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. 

Comment 5 by f...@opera.com, Mar 28 2016

Labels: Needs-Bisect
Maybe we could try a bisect to see if we'll be any the wiser.

Comment 6 by f...@opera.com, Mar 28 2016

Labels: -OS-Mac OS-All
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.
Cc: nyerramilli@chromium.org
Labels: -Needs-Bisect M-51
Owner: shanmug...@samsung.com
Status: Assigned (was: Unconfirmed)
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/ 
@nyerramilli,
 Thank you for notifying me!! I will take care of this issue..
Labels: hasbisect
Status: Started (was: Assigned)

Comment 13 by f...@opera.com, 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.
@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/
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.

Comment 16 by f...@opera.com, 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.

Comment 17 by f...@opera.com, Apr 1 2016

Mergedinto: 470608
Status: Duplicate (was: Started)

Sign in to add a comment