466604 - Illegal characters in comments result in comments being cut off after the illegal character(s)

Status: RESOLVED INVALID

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Chris Lawson (gone)]

STR:

1) Paste something into a Bugzilla comment form that contains illegal characters. (I apologise for not being able to be more specific about what constitutes an 'illegal' character, but copy a few lines out of one of the Mozilla dylibs as viewed in a text editor and you'll probably get one.)

2) Submit the comment.

ER: Comment submits with illegal characters replaced by...I dunno, *something*.

AR: Comment submits but cuts off any content on the same line as an illegal character. So, for instance, if the asterisk were an illegal character, the comment 

"The quick brown fox jumped over the lazy dog.

The *quicker* brown fox jumped over the lazy dog, too."

would be missing everything after the second carriage return.

I checked the page source; Bugzilla is actually stripping the content rather than just putting it on the page in a non-renderable way.

Comment 1

[Vitaly Fedrushkov]

1. Buzgilla version is not specified.
2. Is 'utf8' Bugzilla parameter set?
3. MySQL database character set?
4. What browser encoding was used?
5. What browser/version was used?

Comment 2

[Chris Lawson (gone)]

This happened with a Camino trunk nightly on bugzilla.mozilla.org. I have no idea what the answers to 2, 3, or 4 are.

Comment 3

[Vitaly Fedrushkov]

You should know at least 4 and 5, both are on your client side :-)

Could you specify URL of a bug with sample truncated comment?

Comment 4

[Chris Lawson (gone)]

https://bugzilla.mozilla.org/show_bug.cgi?id=466531

Comment 5

[Frédéric Buclin]

I can paste the content of the URL mentioned in bug 466531 comment 23 without any problem. Could you try again and if you can still reproduce the problem, please attach the strings you pasted here.

Comment 6

[Chris Lawson (gone)]

That URL doesn't have the illegal characters in it (pastebin has the same behaviour as Bugzilla in this regard).

Comment 7

[Frédéric Buclin]

justdave, could you check the content of bug 466531 comment 21 and bug 466531 comment 22 directly in the DB, and see if the data stored in the DB is truncated or not?

Comment 8

[Frédéric Buclin]

If the data in the DB is truncated, could it be that Camino itself removes illegal characters and stuff following them?

Comment 9

[Chris Lawson (gone)]

(In reply to comment #8)
> If the data in the DB is truncated, could it be that Camino itself removes
> illegal characters and stuff following them?

To test that theory, I'm going to try it with Firefox 3.

 ˛∫æ

Comment 10

[Chris Lawson (gone)]

Firefox 3 has the same problem ;)

Comment 11

[Dave Miller [:justdave]]

I see exactly the same thing in the database that I see on the Bugzilla web page for all three comments (the two referenced in comment 7, and comment 9 on this bug).

Comment 12

[Frédéric Buclin]

(In reply to comment #11)
> I see exactly the same thing in the database that I see on the Bugzilla web
> page for all three comments (the two referenced in comment 7, and comment 9 on
> this bug).

...which makes me think the data is lost when submitting data. Could it be that browsers intentionally omit such "illegal" characters? Firefox and Camino are both based on Gecko, which could explain the common behavior mentioned above.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Using Chris's steps to reproduce, he's pasting some data including 0-valued PRUnichars into the textarea.  When he submits, we end up in nsFSURLEncoded::URLEncode, which ends up passing the data around as a PRUnichar*, so it gets truncated at the first null.

Honestly, I don't have a problem with that behavior.

Comment 14

[Frédéric Buclin]

(In reply to comment #13)
> Honestly, I don't have a problem with that behavior.

Same here. And this means it's not a Bugzilla bug.

Comment 15

[Chris Lawson (gone)]

Filed the Widget:Cocoa bug as bug 481457.