There has been other reports that XML parsing has failed for certain types of documents ( issue 820163  for instance.) So under the assumption that the payload here is indeed an XML document, this could have the same underlying cause. My reading of the above links is that you get two Text nodes where you previously got one - is that correct? Could you provide an example response (or a way of reproducing the issue)?

(FWIW, if you're getting multiple siblings Text nodes, you could work around it by calling Node.normalize() on the XML document/fragment root before using the document/fragment.)

On the second link (https://www.essentialobjects.com/forum/postst10828_Chrome-65-callback.aspx), one of the comments gives a test example, with code, replicating this issue here: http://webshop.langauto.hu/callback.aspx 

It uses a callback component (eo:callbackpanel) to return a random string in the response. If 100000 is entered as the length of the string, it returns and loads to the page. If you enter 300000, it does not load to the page (but the poster says there is a response from the server). This previuosly worked in 64, and works in other browsers.

Thanks! Easily verifiable there, and in this case it's the/a CDATA that ends up being split. Doesn't look like XHR is to blame.

Able to reproduce the issue on reported version 65.0.3325.146 and latest chrome 67.0.3370.0 using Mac 10.12.6, Ubuntu 14.04 and Windows-10, as the break is on 65.0.3325.0 branch builds, hence providing manual change log from omahaproxy

Bisect Info:
================
Good build: 65.0.3325.68
Bad build: 65.0.3325.69

https://chromium.googlesource.com/chromium/src/+/9dc050f2480deaf9882ca95a6f214cc552ef9339

Change-Id: Id2fa1d96e55be1e0483c135c20c20b90a068f4c3
Reviewed-on: https://chromium-review.googlesource.com/897220

@Joel Hockey: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable for M-65 as it is seems a recent break, feel free to remove it if not applicable.

Thanks!

I'm sorry, I'm no longer working in chromium, so I wont be able to look into this.  I suspect that this bug may be related to the XML changes described in  issue 820163 .  I give some suggestions there about possible solutions, including rolling back the change I made.

+schenney@ , could you ptal comment #8 and mark this as dupe if needed?

It's probably a duplicate but I know nothing about this kind of thing, so would have to defer the decision.

Pls verify this fix on canary version 67.0.3372.1+. Thank you.

Able to reproduce the issue on chrome reported version 65.0.3325.146
Verified the fix on Windows-10, Ubuntu 14.04, Mac 10.13.1 on Chrome version #67.0.3375.0 as per the comment#0
Attaching screen shot for reference.
Observed "Able to see DOM response"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 821536.png 785 KB

	821536.png 785 KB View Download

Is the plan to apply this fix to v65 too? Any idea of timescales?

The fix has been applied to the M-65 branch, so it should be making its way out in due time.

Yes, with high probability the fix will go to users this week.