User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

View this jsfiddle page: https://jsfiddle.net/3toj6pmr/3/

Note: the tspan on this page uses a custom woff font with a very limited character set. The tspan has x and y attributes to precisely specify the location for each character displayed.

Actual results:

The tspan is rendering the glyph for the first character in two different locations.

Expected results:

Just one copy of the first character glyph should be visible, in the correct location.

Both Chrome and Edge display the first glyph just once, in the correct location.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Hi,

I have managed to reproduce this issue on latest FF release 72.0.2, Beta 73 and latest Nightly build 74.0a1 (2020-02-10) using Windows 10.
Further, I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Thanks for the report. Here's a screenshot of the reporter's testcase, and I believe the issue is that there are two slash marks at the bottom left (rather than one). I'm testing on Linux, BTW.

The second slash-mark goes away if I remove the x attribute from the tspan element, or if I collapse that attribute down to just a single numeric value (rather than a list). So I think it's related to the multi-value x attribute here (which normally would set the placement of each character, but in this case I think there's only meant to be a single combined character at a single position (?))

The bug becomes more obvious if I use a larger difference between the "x" values. Testcase coming up.

It appears we've had this behavior for quite a while. mozregression give this range:

INFO: Last good revision: cbb24a4a96af (2013-06-30)
INFO: First bad revision: d7553251cf43 (2013-07-01)
INFO: Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cbb24a4a96af&tochange=d7553251cf43

...which means this was a regression from bug 839955. Before the regression range, we only drew the left slash (of the two). I'm not sure if that's correct or not, but it was not-redundant at least (as compared to our current behavior).

Anyway; calling this P3 (the categorization we use for most of our bugs). Thanks again for the report!