Obsolete
Status Update
No update yet.
Comments
sh...@gmail.com
Works perfectly on chrome Version 49.0.2623.112 m.
Possibly a regression !
Possibly a regression !
aj...@chromium.org
[Empty comment from Monorail migration]
sh...@gmail.com
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?
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?
du...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: -Blink Blink>SVG]
[Monorail components: -Blink Blink>SVG]
kk...@chromium.org
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....
Thank You....
sh...@gmail.com
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.
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.
fs...@opera.com
I wonder if this could be the same as https://crbug.com/chromium/638894 - which has been elusive thus far =(.
ai...@gmail.com
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
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]
fs...@opera.com
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.)
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.)
fs...@opera.com
Re: c#8, that does sound like it would be https://crbug.com/chromium/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.
ai...@gmail.com
Thanks, I've added the TC to https://crbug.com/chromium/665387 . I'm assuming it's better to track it there rather than opening another specific issue?
fs...@opera.com
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!)
sc...@chromium.org
Is this issue superseded by 665387? Close this one? Make dependent on 665387?
fs...@opera.com
ai...@gmail.com
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).
sh...@gmail.com
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
May I know if we are fixing this issue in the next build release and when are we targeting the same?
Thanks in advance
fs...@opera.com
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?
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?
sh...@gmail.com
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.?
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.?
fs...@opera.com
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>.)
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>.)
sh...@gmail.com
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.
Thanks for the quick workaround!.Let me know if u need any info from my side around this issue.Thanks again.
fs...@opera.com
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...
kk...@chromium.org
shiraazsd@ We are unable to access the HTTP link provided in the https://crbug.com/chromium/673114#c6 , 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 thehttps://crbug.com/chromium/673114#c8 .
Attaching the screencast for your referenece, please look into it and let us know your observations.
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
Attaching the screencast for your referenece, please look into it and let us know your observations.
ai...@gmail.com
Hi kkaluri@, the issue we raised ended up tracked against https://crbug.com/chromium/665387 and is now fixed. Thanks!
sc...@chromium.org
Marking fixed per https://crbug.com/chromium/673114#c23 . Re-open if this is a misunderstanding.
fs...@opera.com
Yes, that was a different issue (one that we managed to repro.)
ra...@chromium.org
@ 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.
Thanks.!
Removing bisect label for now. Please add if required again.
fs...@opera.com
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.)
sh...@chromium.org
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 visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
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
sc...@chromium.org
At this point it is WontFix. The user has a workaround, according to https://crbug.com/chromium/673114#c20 and we could never reproduce the original issue.
is...@google.com
This issue was migrated from crbug.com/chromium/673114?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
Steps to reproduce the problem:
A piece of javascript code is retrieved from the server, this code is run on the browser to update the svg element.Hence, svg is rendered dynamically for the 1st time.
What is the expected behavior?
The text withing the different <text> tag must be rendered correctly as per their x, y attributes and not overlap over each other
What went wrong?
Issue is with the <text> tag in the svg not rendering properly. The <text> tag does not follow the positions x,y as mentioned in its attributes. Instead it just stays at the origin(0, 0) because of which each of the text within different <text> tag overlaps over each other.Refer to the attachment "Faulty.png".
However, the text gets positioned correctly automatically in the following cases:-
1)The size of the browser window is changed
2)Any of the elements in the <svg> tag is altered via the developer tool
Refer to the attachment "correct.png".
From the above 2 points it appears that the svg itself is not rendered properly at the first load(dynamically). As soon as we do any of above 2 points chrome renders the svg correctly.
Did this work before? N/A
Chrome version: 55.0.2883.75 Channel: n/a
OS Version: 8.1
Flash Version: Shockwave Flash 23.0 r0
Although the full svg code is quite big but here is the HTML piece responsible for rendering the svg text
<svg xmlns="
<g transform="matrix(57.22751322751323,0,0,57.22751322751323,360.6538835978836,26.883768888888916)">
<g>
<text font-size="1" style="font-family:'Arial', sans-serif; stroke:none; fill:black;" transform="scale(0.048895)" x="-10.779220779220779" y="2.1136363636363633">
<tspan x="-10.779220779220779">Overlapping text</tspan>
<tspan dy="1em" x="-10.779220779220779">Overlapping text</tspan>
</text>
<text font-size="1" style="font-family:'Arial', sans-serif; stroke:none; fill:black; font-weight:bold;" transform="scale(0.08001)" x="-6.587301587301588" y="-0.75">
<tspan x="-6.587301587301588">Overlapping text</tspan>
</text>
</g>
</g>
</svg>