941940 - U+000D 'CARRIAGE RETURN (CR)' is rendered as a hexbox

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[Jesse Ruderman]

Attachment: simple testcase

Using Firefox Nightly on Mac OS X 10.9, pages that contain carriage return characters show an '000D' hexbox.  This does not happen in Safari or Chrome on the same computer.

I expected it to be treated as whitespace, although other browsers seem to ignore it entirely.

Comment 1

[Jesse Ruderman]

Attachment: Screenshot: affected Twitter bio

Comment 2

[Chris Peterson [:cpeterson]]

This bug is a regression in Nightly 28. This bug is not reproducible in Aurora 27, Beta 26, or Firefox 25.

Comment 3

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/e9370b4c4ace
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131112001830
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/739edf98ca0b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131112003631
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e9370b4c4ace&tochange=739edf98ca0b
Regressed by:
739edf98ca0b	Jonathan Kew — bug 909344 - render stray control characters as hexboxes instead of invisible. r=roc

Comment 4

[Jesse Ruderman]

I'm seeing this on quite a few Twitter bios. No idea why CRs are common there.

Comment 5

[Jonathan Kew [:jfkthame]]

The example in question includes explicit 
 entities:

  <p class="bio profile-field">Reach more than 85% of the US business population with the Bizo Marketing Platform.&#13;&#10;&#13;&#10;Want to love your job? Join us!

I guess there's some Windows-based tool people are using to maintain Twitter accounts that (inappropriately) does this entity-encoding of the CRLF sequence if it occurs within certain fields - maybe an attempt to allow newline sequences within fields that at some level may be defined as single-line?

If this seems to be a common pattern, I suppose we should include <CR> in the characters that we always render as invisible.

Comment 6

[Jonathan Kew [:jfkthame]]

I see that the question of how stray 
s in the DOM should be treated has come up before; e.g. bug 534071.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: don't render stray <CR> characters (&#13; entities) in the DOM as hexboxes, just leave them invisible

Something like this should make the stray CRs disappear again. (Although they really shouldn't be there in the first place.)

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: reftest to check that &#13; characters in the DOM remain invisible

And let's have a simple reftest for this.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8336713 [details] [diff] [review]
reftest to check that 
 characters in the DOM remain invisible

Review of attachment 8336713 [details] [diff] [review]:
-----------------------------------------------------------------

You forgot to hg add the files

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: reftest to check that &#13; characters in the DOM remain invisible

Oops, so I did. This should be better.

Comment 11

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/040798d3721c
https://hg.mozilla.org/integration/mozilla-inbound/rev/383361e75e5d

Comment 12

[Jonathan Kew [:jfkthame]]

Oops... I must have goofed when rebasing this to inbound; the line adding the new test to bugs/reftest.list got lost. :( Pushed a followup to fix that. (Also corrected the order of the last few entries there, as they weren't sorted properly.)

https://hg.mozilla.org/integration/mozilla-inbound/rev/ac5ac0a2b106

Comment 13

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/040798d3721c
https://hg.mozilla.org/mozilla-central/rev/383361e75e5d
https://hg.mozilla.org/mozilla-central/rev/ac5ac0a2b106

Comment 14

[Ekanan Ketunuti]

reproduced on nightly 28.0a1 20131123030208 build.
verified on nightly 28.0a1 20131128030201 build.