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