Closed Bug 415391 Opened 16 years ago Closed 16 years ago

Corrupted text in JavaScript alert dialog (error message issued by Acid3 test 68 when Acid3 test 68 fails)

Categories

(Core :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 421576

People

(Reporter: reed, Unassigned)

References

Details

(Keywords: regression)

Attachments

(4 files)

The text after "test 68" in the acid3 JS alert dialog is corrupted with missing characters.

I noticed this issue the other day when I was looking at our current status on acid3, but I couldn't reproduce it. Well, I just reproduced it again. This is a fairly recent regression (last two weeks, I think?).
Flags: blocking1.9?
Which build passed Acid3 test 68? 
It's merely that Acid3 test 68 still fails, isn't it?.

Escaped data of variables are as follows.
>(Seamonkey 1.1.7)
> before : length=5,escaped_data=%uD863text
>  after : length=3,escaped_data=ext
>(Fx trunk 2008-01-27-04 build).
> before : length=5,escaped_data=%uD863text
>  after : length=4,escaped_data=%uFFFDext
>          (It looks that "%uD863t" was converted to %uFFFD.)
>          (Acid3 test 68 expects %uFFFDtext.)

Script for Acid3 test 68 uses following for final error message.
> fail("Unpaired surrogate handled wrongly (input was '" + before + "', output was '" + after + "')");

When Seamonky 1.1.7 before(%uD863text) is converted to after(ext) in Acid3 test 68. But on alert or HTML rendering of before(%uD863text), %uD863 part looks to be displayed by font for U+FFFD because font for U+D863 doesn't exists.

When Fx trunk, before(%uD863text) is displayed as %uFFFDext on alert/HTML rendering by Fx, because of currently occurring "Acid3 test 68 failure(==converted to %uFFFDext)", and after(%uFFFDext) is displayed as-is.

Acid 3 test 68 should use escape() for error message, because this is final error message for test 68 failure.
> fail("Unpaired surrogate handled wrongly (input was '" + escape(before) + "', output was '" + escape(after) + "')");
Attachment #301198 - Attachment mime type: text/plain → text/html
Correction of result on Fx trunk.
Above "%uD863text looks to be displayed as %uFFFDext" is for your screen shot on Linux.
When Fx trunk 2008-01-27 build on MS Windows XP SP2, before(%uD863text) part was displayed as if " text" when Japanese font, and %uD863 was displayed as a character for hex data when English font.
> +--+
> |D6|
> |83|text 
> +--+

Display/rendering result seems to depend on environment(OS, Font etc.) 
Test result with Tb trunk 2007/12/03 & 2008/1/02 was same as one with Tb trunk 2008/1/27 build, when MS Win-XP SP2. (before==%uD863text, after==%uFFFDext)
I use Japanese MS Windows XP. So system font is MS Gothic/Mincho.
 (1) Alert        : Font=MS Gothic(or MS UI Gothic)
 (2) Left screen  : Font=Times New Roman (character encoding=iso-8859-1)
 (3) Right Screen : Font=MS Gothic (character encoding=utf-8)

Display of %uD863text as if %uFFFDext in alert(your screen shot) is not observed on Japanese MS Win-XP SP2.
WFM on Mac.

A reduced testcase would be useful.
(In reply to comment #6)
> A reduced testcase would be useful.

Minimu test case is following.
> javascript: var x=String.fromCharCode(0xd863)+'text';alert(x);
Screen shot of Comment #0 says that same glyphs as u%FFFDext(no 't') is displayed by alert on Linux.
Screen shot of Comment #5 says that same glyphs as ' text' is displayed by alert on MS Win, and "square box" seems to be glyph for U+FFFD when font used by alert in my environment.
But it's difficult to see what data is displayed when above minimum case.
So next is better. 
> javascript: var x=String.fromCharCode(0xd863)+'text';alert(x+'\n'+escape(x));

To compare with above alert case with current handling of %uD863text in HTML, and to see that displayed glyphs depends on font, I added p_element.innerHTML=%uD863text & escape(%uD863text) in test case of Comment #2. And, to see that Acid3 test 68 still fails, whole logic of test 68 except function of fail() is kept in it.  
Is this affecting the display of international characters in JS alerts? We're trying to guage the impact here. We're not blocking on ACID3 compliance, but if this is an l10n issue, please renominate.
Flags: blocking1.9? → blocking1.9-
(In reply to comment #8)
> Is this affecting the display of international characters in JS alerts?

No.
This bug's issue is merely "inconsistent/unexpected display of invalid Unicode data in alert", if problem of this bug by bug opener is not "Acid3 test 68 still fails".
> invalid Unicode data == Half of surrogate pair (0xd863 when Acid3 test 68)
>    surrogate : U+D800 to U+DFFF. Used as "surrogate pair" only
> inconsistent display of %uD863text in alert ==
>  %uD863text was displayed like %uFFFDext by alert in bug opener's environment,
>  but was displayed like ' text' in my environment.

Since objective of alert when Acid3 test 68 is "report failure of test 68 to user", Acid3 test 68 should report it by "alert(escape(invalid_Unicode_data));".

If problem of this bug by bug opener is "%uD863text was displayed as %uFFFDext(no 't')" part, this is simply a result of "Acid3 test 68 still fails" and current failure is "%uD863text is converted to %uFFFDext(no 't')".
Bug for "Acid 3 test fails" has been opened. (Bug 421576)
Depends on: 421576
Summary: Corrupted text in JavaScript alert dialog → Corrupted text in JavaScript alert dialog (error message issued by Acid3 test 68 when Acid test 68 fails)
Summary: Corrupted text in JavaScript alert dialog (error message issued by Acid3 test 68 when Acid test 68 fails) → Corrupted text in JavaScript alert dialog (error message issued by Acid3 test 68 when Acid3 test 68 fails)
(In reply to comment #0)
> This is a fairly recent regression (last two weeks, I think?).

To Reed Loden(bug opener):

Which do you mean by your "regression" and "regression" in Keywords: field?
 A. in a limited sense: Already fixed problem appeared again, due to some changes
 B. in a broad sense  : New problem appeared, due to some changes
Which phenomenon/part is the "recent regression", in phenomena observed while Acid3 test68 or screen-shot by you?
(In reply to comment #12)> 
> Which do you mean by your "regression" and "regression" in Keywords: field?

I mean: >  B. in a broad sense  : New problem appeared, due to some changes

> Which phenomenon/part is the "recent regression", in phenomena observed while
> Acid3 test68 or screen-shot by you?

I have run Acid3 a lot since Hixie first mentioned it in #developers for us to check out, and this was the first time I saw that particular problem. It could be because Hixie changed something in the test, but who knows.
(In reply to comment #13)
> this was the first time I saw that particular problem.
Which part is the "particular problem"?

> Hixie first mentioned
Ian Hixon (ian@hixie.ch)? 

> It could be because Hixie changed something in the test, but who knows.

As I wrote in Comment #2, if test 68 uses  fail(...+escape(before)+...+escape(after)+...), escape(before) part is %uD863text since initial, and escape(after) part depends on Mozilla build.
And, as I wrote Comment #7, displayed glyph by alert(String.fromCharCode(0xd863)+'text') looks to depends on environment(OS, locale, font, etc.).
I can't think that something in test 68 is changed.
(In reply to comment #6)
> WFM on Mac.

To Jesse Ruderman:  
What do you mean by WFM? WFM with which build?
 1. Bug 421576 won't occur when Mac
 2. Can not observe loss of 't' in error message of "Acid3 test 68 failure",
    even with latest-trunk when Mac, at both alert(...+before+...) part and 
    alert(...+after+...) by fail(...+before+......+after+...) in Acid3 test 68
    when Acid3 test 68 fails.
FYI.
Bug 421546 is bug for confusing error message by Acid3 test 68 when Acid3 test 68 fails. (Acid3 test 68 is better to use fail(...+escape(before)+...))
(In reply to comment #0)
> The text after "test 68" in the acid3 JS alert dialog is corrupted with missing
> characters.

To Reed Loden(bug opener):

Does your 'text after "test 68"' mean following?
  - Message text in lines after error message line for "test 68 failure"
    (i.e. message line for "test 68 failure" itself is not involved)
Does your 'corrupted with missing characters' mean following?
 - Text of "Test 0:", "Test 1:" etc. in error message of test 70,71,... failure,
   and loss of first character of each word in the error message.
   Not lost 't' of 'text' in error message of test 68 failure.
(sorry but I misunderstood these were really Test 0, Test 1,... in other series of tests after test 68)

Now that we handle the unpaired surrogates correctly, there is no more corrupted text.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: