Bug 87465 – &AElig doesn’t get rendered as U+00C6

• Component: DOM
• Status: RESOLVED FIXED

[Mathias Bynens]

&Aelig doesn’t get rendered as U+00C6. Kinda weird, as the entry in Source/WebCore/html/parser/HTMLEntityNames.in looks alright: http://trac.webkit.org/browser/trunk/Source/WebCore/html/parser/HTMLEntityNames.in#L2

Minimal test case: data:text/html,foo%20%26AElig%20bar

Up-to-date tests for named character references: http://mathias.html5.org/tests/named-character-references/

Spec: http://whatwg.org/html/named-character-references.html

[Mathias Bynens]

(In reply to comment #0)
> &Aelig doesn’t get rendered as U+00C6.

Sorry, that should have said `&AElig`, not `&Aelig` (which isn’t a named character reference at all).

[Peter Beverloo]

Created attachment 144065 [details]
Patch

[Peter Beverloo]

Adam, do the encoding artifacts in entity-table-first-alphabetic-entry-expected.txt matter? Alternatively I guess a reftest comparing &AElig to Æ (mind the semi-colon) would work here.

[WebKit Review Bot]

Comment on attachment 144065 [details]
Patch

Attachment 144065 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12795537

New failing tests:
fast/parser/entity-table-first-alphabetic-entry.html

[WebKit Review Bot]

Created attachment 144067 [details]
Archive of layout-test-results from ec2-cr-linux-02

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Peter Beverloo]

Created attachment 144068 [details]
Patch

[WebKit Review Bot]

Comment on attachment 144068 [details]
Patch

Attachment 144068 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12804502

[Gustavo Noronha (kov)]

Comment on attachment 144068 [details]
Patch

Attachment 144068 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/12799555

[Early Warning System Bot]

Comment on attachment 144068 [details]
Patch

Attachment 144068 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/12803501

[Build Bot]

Comment on attachment 144068 [details]
Patch

Attachment 144068 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12793489

[Early Warning System Bot]

Comment on attachment 144068 [details]
Patch

Attachment 144068 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/12801473

[Gyuyoung Kim]

Comment on attachment 144068 [details]
Patch

Attachment 144068 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/12807476

[Peter Beverloo]

Comment on attachment 144065 [details]
Patch

Ugh, empty lines aren't being appreciated :-). Let's stick with Patch 1 for now then. Any ideas on how to get the bots to regenerate the file?

[Adam Barth]

Comment on attachment 144065 [details]
Patch

The code change looks fine.  Please consider adding the test to http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/resources/entities02.dat instead.  Don't worry about the encoding problems.  That's the fault of the review tool, not of the code we're testing.

[Peter Beverloo]

Created attachment 144317 [details]
Patch

[Adam Barth]

Comment on attachment 144317 [details]
Patch

Looks great.  Thanks!

[Peter Beverloo]

Comment on attachment 144317 [details]
Patch

Thanks!

[WebKit Review Bot]

Comment on attachment 144317 [details]
Patch

Clearing flags on attachment: 144317

Committed r118672: <http://trac.webkit.org/changeset/118672>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Chris Dumez]

This patch appears to have caused 2 failures on EFL and GTK ports:

Regressions: Unexpected text diff mismatch : (2)
  fast/tokenizer/entities-01.html = TEXT
  fast/tokenizer/entities-03.html = TEXT

The diff looks like:
--- /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/layout-test-results/fast/tokenizer/entities-03-expected.txt
+++ /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/layout-test-results/fast/tokenizer/entities-03-actual.txt
@@ -1,4 +1 @@
-FAIL:
-
-AElig (was: &AElig, expected: Æ (\uc6))
-
+PASS

[Chris Dumez]

(In reply to comment #20)
> This patch appears to have caused 2 failures on EFL and GTK ports:
> 
> Regressions: Unexpected text diff mismatch : (2)
>   fast/tokenizer/entities-01.html = TEXT
>   fast/tokenizer/entities-03.html = TEXT
> 
> The diff looks like:
> --- /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/layout-test-results/fast/tokenizer/entities-03-expected.txt
> +++ /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/layout-test-results/fast/tokenizer/entities-03-actual.txt
> @@ -1,4 +1 @@
> -FAIL:
> -
> -AElig (was: &AElig, expected: Æ (\uc6))
> -
> +PASS

I think those tests just need new baselines now that the &Aelig bug was fixed.

[Peter Beverloo]

(In reply to comment #20)
> This patch appears to have caused 2 failures on EFL and GTK ports:
> 
> Regressions: Unexpected text diff mismatch : (2)
>   fast/tokenizer/entities-01.html = TEXT
>   fast/tokenizer/entities-03.html = TEXT
> 
> The diff looks like:
> --- /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/layout-test-results/fast/tokenizer/entities-03-expected.txt
> +++ /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/layout-test-results/fast/tokenizer/entities-03-actual.txt
> @@ -1,4 +1 @@
> -FAIL:
> -
> -AElig (was: &AElig, expected: Æ (\uc6))
> -
> +PASS

Sorry for that! It seems like this patch actually fixed the bug, so a rebaseline of the test should be sufficient..

[Chris Dumez]

Doing rebaseline in Bug 87648.