Bug 38984 - document.documentElement cannot be replaced
Summary: document.documentElement cannot be replaced
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-12 04:43 PDT by gildas
Modified: 2023-08-23 09:54 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gildas 2010-05-12 04:43:04 PDT
I have an issue when I run this script after a page is loaded into the web developer console on chrome and safari : 

doc = document.documentElement.cloneNode(true); 
document.replaceChild(doc, document.documentElement); 

It should replace the document element by its clone and remain intact. Most of the time, the page becomes blank or style sheets are not interpreted.

For example, on http://groups.google.com/a/chromium.org/group/chromium-extensions/browse_thread/thread/2f56dc162846c27b/017a1f103d5bf795#017a1f103d5bf795. 

All I get is a blank page with only 3 "script" elements in the "head" of and no "body" element in the document on chrome. On safari, I see is an additional "script" element after the 3 "style" elements.

This bug does not happen with firefox 3.6.3, opera 10.53 and ie8 for the same URL.
Comment 2 Alexey Proskuryakov 2010-05-12 14:24:14 PDT
Do you have a complete test case that demonstrates a specific problem?
Comment 3 gildas 2010-05-12 16:09:56 PDT
(In reply to comment #2)
> Do you have a complete test case that demonstrates a specific problem?

Sorry, I didn't read carefully the bug reporting guidelines. I didn't know I had to attach a test case. I have switched "Component" to "New Bugs".
Comment 4 Alexey Proskuryakov 2010-05-12 16:23:40 PDT
You don't have to, but having a test case - or steps to reproduce with a live Web site - makes it much clearer what problem is being discussed.
Comment 5 gildas 2010-05-12 16:54:52 PDT
(In reply to comment #4)
> You don't have to, but having a test case - or steps to reproduce with a live Web site - makes it much clearer what problem is being discussed.

Ok,

Here are the detailed steps to reproduce the bug.

1 - open a new window/tab
2 - enter this URL : http://groups.google.com/a/chromium.org/group/chromium-extensions/browse_thread/thread/2f56dc162846c27b#
3 - wait until the page is fully loaded
4 - open the web developer javascript console (ctrl-shift-j on chrome, ctrl-option-i on safari)
5 - type into the input console : document.replaceChild(document.documentElement.cloneNode(true), document.documentElement); 
6 - press enter
7 - the page becomes blank

Expected result : the page should not become blank. It should remain intact since this script replace document.documentElement by its clone.
Comment 6 Alexey Proskuryakov 2010-05-12 17:12:53 PDT
Confirmed with r59249.

One more question: why is this important? WebKit isn't really prepared for such drastic changes to an existing document, so this may not be an easy fix.
Comment 7 gildas 2010-05-12 17:31:45 PDT
(In reply to comment #6)
> Confirmed with r59249.
> 
> One more question: why is this important? WebKit isn't really prepared for such drastic changes to an existing document, so this may not be an easy fix.

Actually, I have done an extension for chrome which does heavy DOM modifications to embed all external resources into the page. Here is the extension link :
https://chrome.google.com/extensions/detail/mpiodijhokgodhhofbcjdecpffjipkle/publish-accepted

It's really better to do all those DOM modifications in a cloned DOM for speed issue (because the browser do not have to render DOM modifications). The extension have no issues to embed images, css, frames resources but when the extension try to embed an external script into the documentElement node, the issue appears. In this case, the only way I found to bypass this issue is to work directly on the document.documentElement.

I think it may be a small bug since scripts are the only resources that cause this issue. 

Also, I think Rich Text Editors may suffer from this issue.
Comment 8 gildas 2010-06-13 14:31:37 PDT
> Actually, I have done an extension for chrome which does heavy DOM modifications to embed all external resources into the page. Here is the extension link :
> https://chrome.google.com/extensions/detail/mpiodijhokgodhhofbcjdecpffjipkle/publish-accepted
> 

Sorry for the mistake, The good URL is https://chrome.google.com/extensions/detail/mpiodijhokgodhhofbcjdecpffjipkle
Comment 9 Chris Dary 2010-06-30 16:52:24 PDT
Just a "me too" here - I'm having issues due to this particular bug as well.
Comment 10 Chris Dary 2010-06-30 17:04:14 PDT
(In reply to comment #9)
> Just a "me too" here - I'm having issues due to this particular bug as well.

I might as well say where so you don't think this is a huge edge case: In the Readability bookmarklet, I was looking to speed up the "reload". Rather than just doing a real reload, I decided to cache the DOM object before I make any changes and then reload it after the fact.

It works on all browsers except webkit-based ones.
Comment 11 Anne van Kesteren 2023-08-23 07:51:12 PDT
Seems to work fine these days.
Comment 12 gildas 2023-08-23 09:54:20 PDT
I confirm I cannot reproduce this bug anymore. Moreover, I ported it recently for Safari. The code of the annotation editor integrated in SingleFile uses this technique and it works totally fine.