| 1 |
See comment below inline in the patch.
|
| 2 |
It'd be nice to fix this properly but that will require upstream WebKit
|
| 3 |
changes; for now, we can just patch out some code to keep behavior as it
|
| 4 |
was before.
|
| 5 |
|
| 6 |
diff --git a/third_party/libxml/parser.c b/third_party/libxml/parser.c
|
| 7 |
index 3ba2a06..4a3cde5 100644
|
| 8 |
--- a/third_party/libxml/parser.c
|
| 9 |
+++ b/third_party/libxml/parser.c
|
| 10 |
@@ -11545,6 +11545,20 @@ xmldecl_done:
|
| 11 |
int cur = ctxt->input->cur - ctxt->input->base;
|
| 12 |
int res;
|
| 13 |
|
| 14 |
+ /* Chromium note: commenting out the following block of code is a gory
|
| 15 |
+ * hack, meant to partially undo
|
| 16 |
+ * http://git.gnome.org/browse/libxml2/commit/?id=a6c76a
|
| 17 |
+ *
|
| 18 |
+ * WebKit and libxml disagree about who is responsible for the
|
| 19 |
+ * document encoding.
|
| 20 |
+ *
|
| 21 |
+ * This bug:
|
| 22 |
+ * https://bugs.webkit.org/show_bug.cgi?id=30508
|
| 23 |
+ * has links to test cases, libxml bug reports, and mailing list threads
|
| 24 |
+ * arguing about it; for now, though, we can just undo the change that
|
| 25 |
+ * caused libxml to regress.
|
| 26 |
+ */
|
| 27 |
+#if 0
|
| 28 |
/*
|
| 29 |
* Specific handling if we autodetected an encoding, we should not
|
| 30 |
* push more than the first line ... which depend on the encoding
|
| 31 |
@@ -11580,6 +11594,7 @@ xmldecl_done:
|
| 32 |
remain = 0;
|
| 33 |
}
|
| 34 |
}
|
| 35 |
+#endif
|
| 36 |
res =xmlParserInputBufferPush(ctxt->input->buf, size, chunk);
|
| 37 |
if (res < 0) {
|
| 38 |
ctxt->errNo = XML_PARSER_EOF;
|
Parent Directory
| 
Revision Log