Works perfectly on chrome Version 49.0.2623.112 m.
Possibly a regression !
 

As this issue is a blocker for the next release of our application for which we have the recommended browser as Chrome. Can you help us with the following ?

1)Is there a way to force reload svg in chrome?
2)What could be an alternative to using <text> tag for positioning text in the svg?
3)Any other quick solutions?

 shiraazsd@ In order to triage this issue could you please provide the sample html file, so that we can test this issue from our end.

Thank You....

Here is a link to my test machine.You can perform the following steps to reproduce the issue

http://54.176.137.98:8080/nrm

1)Login:
Username : nrm
Password : password

2)Click on "Facility Designer"

3)On the left side under the Hierarchy tab tree

-Click plus sign to expand "Default Map001"
-Then click plus sign to expand "Default Map001-Plan001"
-Then double click on Plan001-Rack001

This will bring up the screen that has text overlapping over each other.i.e. the text withing the <text> tag is not positioned as per the x,y attributes.

Changing the window size even slightly automatically fixes the issue.Let me know if you need any more details.

I wonder if this could be the same as issue 638894 - which has been elusive thus far =(.

I was just about to submit a report for a similar sounding bug that we've reduced to a specific commit [1]. There are other bugs in the tracker that sound similar (#665387, #664961).

The behaviour is that text elements that have a transform attribute are not positioned correct on zoom. I've attached a minimal example.

We've tested on Windows and Mac and they both exhibit the same behaviour after the release of version 434934.

[1] https://chromium.googlesource.com/chromium/src/+/f72170ee0164e5d4bcf14551603907ffafd969f1

Deleted: Screenshot example.png 13.8 KB

	Screenshot example.png 13.8 KB View Download

Deleted: example.svg 703 bytes

example.svg 703 bytes Download

As a workaround, could you try to either move the:

transform="scale(0.0...)"

to the containing (parent) <g>, or adjust the scale on the grand-parent <g> (57.2275... * 0.048895 -> 2.7...; with font-size adjusted too probably.)

It looks a bit like the font selected during initial attach/style recalc somehow does not get updated during layout (which I believe it should.)

Re: c#8, that does sound like it would be  issue 665387 , which would be more pronounced after the mentioned commit (r434934) - i.e now you'll get that issue with a 'transform' attribute as well. Feel free to drop your TC there as well, I'll see if I can get fix done for that.

Thanks, I've added the TC to  issue 665387 . I'm assuming it's better to track it there rather than opening another specific issue?

Yes, the fix should be the same both for that and the original issue (now, after r434934), so no need for a specific issue. Thanks for adding the test there, and for the report (extra plus for the bisect!)

Is this issue superseded by 665387? Close this one? Make dependent on 665387?

 Issue 665387  is likely unrelated (the change mentioned above landed in 57, so it cannot be at play for the reporter.) It's however possible that this is a dupe of issue 638894. Lacking proper debugging (or reproduction for that matter), it hard to say for sure though, even if the symptoms appear very similar.

Not sure if it helps but I can't reproduce the bug listed in this issue (in 55.0.2883.87, 55.0.2883.75, 57.0.2949.0 or 57.0.2950.0).

Re: c#9, I tried putting the <text> tag inside a <g> tag.Moved the transform from <text> tag to the parent <g> tag and made the the transform scale > 0.5 as mentioned in 638894. Also readjusted the font size a bit. Didnt really make a difference.It it helps, you can also see the same changes in working on the test machine I shared in the c#6. 
May I know if we are fixing this issue in the next build release and when are we targeting the same?
Thanks in advance

To be able to fix this, we (or, at least someone) need to be able to reproduce the problem (preferably in a reliable way.) Before we can do that, I don't think we can reasonably comment on when the fix will be released.

That being said, it sounds like this is somehow caused by dynamic insertion of elements? If you put the markup from the report in a file and load it, will it reproduce still? If not, could you try to describe how you construct and insert the relevant <text> fragments into the document?

Thanks for the reply.I am unable to reproduce the issue actually when using the markup separately. Basically every time the view is rendered for the 1st time, the complete svg is constructed at the backend and sent to frontend embedded inside a javascript code. This code is run and the corresponding svg is updated. We never partially change any specifc tags (<text> fragments ) withing svg. Everytime the complete svg is updated.
Is there a workaround for this which I can try ? or possibly some other svg tags that I can use to position the text within svg element.?

Ok, so  inserted using innerHTML or so? (I would check your demo site, but it seems I'm unable to access it ATM.)

You could use transforms for some of the position (the <text> but not the <tspan>):

 <text ... transform="scale(0.048895)" x="-10.779220779220779" y="2.1136363636363633">

to

 <text ... transform="scale(0.048895) translate(-10.779220779220779, 2.1136363636363633)">

etc. (Everything but the dy=... will then be "0".) Based on the screenshot of the problem though it doesn't look like it would get you all the way there (dy wouldn't work still, so that <text><tspan><tspan> would need to be converted to <text><text>.)

Re:c#19, As suggested on using the translate() instead of x,y in the <text> for positioning, and putting the text inside the <text> tag without using <tspan> fixed the problem. 
Thanks for the quick workaround!.Let me know if u need any info from my side around this issue.Thanks again.

Ok, that's good info... That would seem to indicate that we either fail to invalidate the position values, or that something in the construction of them goes wrong. The apparent platform-dependency makes it feel odd still though...

shiraazsd@ We are unable to access the HTTP link provided in the comment #6, Could you please provide a sample html file to test the scenario on our end.

aidankane@ Unable to reproduce the issue in Windows 10, Ubuntu 14.04 and Mac 10.12.2 with chrome version #55.0.2883.75, from the provided the example.svg file in the comment #8.

Attaching the screencast for your referenece, please look into it and let us know your observations.

Deleted: Issue 673114.mp4 644 KB

	Issue 673114.mp4 644 KB View Download

Hi kkaluri@, the issue we raised ended up tracked against  issue 665387  and is now fixed. Thanks!

Marking fixed per comment #23. Re-open if this is a misunderstanding.

Yes, that was a different issue (one that we managed to repro.)

@ fs: Do we have any update on this issue, Can we have a new test case if any so that we can triage it.

Thanks.!

Removing bisect label for now. Please add if required again.

The status here (at least from my PoV) is that we haven't managed to reproduce this issue (or managed to figure out how it can happen.)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

At this point it is WontFix. The user has a workaround, according to comment #20 and we could never reproduce the original issue.