View Full Version : Document.write and pausing
molendijk
12-02-2016, 03:25 PM
Hello everyone,
I'm playing around with document.write (just for the fun of it). My question is about the following code.
<iframe src="some_file.html" name="probe" onload="external_html=frames.probe.document.body.innerHTML"></iframe>
<script>
alert();document.write(external_html)
</script>The alert pauses parsing until we click on OK. During that brief moment of time, the iframe will have loaded, implying that external_html is 'known' after the click on OK. The result is a page that does not only contain the iframe, but also the innerHTML of the iframe (outside of it). And since we used document.write, every bit of code written in the iframed page will be automatically tranferred to the containing page (and will execute!).
If we leave out the alert, document.write will achieve nothing, because external_html is not known yet at the time document.write is called. A timer won't correct this in a proper manner, because the whole page would be rewritten (and the iframe would not be visible anymore; this also applies to all other content).
In other words, a timeout is not a good replacement of the alert. I tried a javascript sleep function: no result either. So my question: is there some piece of code that does exactly what the alert does except for the appearance of the alert box?
Note: I'm not interested in solutions that use Ajax / that don't use the native document.write.
Thanks.
jscheuer1
12-02-2016, 05:40 PM
You could try a while or a for loop, but I suspect there might be issues with that:
<iframe src="some_file.html" name="probe" onload="external_html=frames.probe.document.body.innerHTML"></iframe>
<script>
while(typeof external_html === 'undefined'){
var who_cares = "knows what?";
}
document.write(external_html)
</script>
Like it might still wipe out the iframe, or it might complain that there's too much looping or recursion going on and ask if you want to continue, which would be a lot like an alert.
But I suppose it's worth a try.
molendijk
12-02-2016, 06:49 PM
You could try a while or a for loop, but I suspect there might be issues with that.
Yes, the browsers complains that there's too much looping. Maybe I should try to solve the issue using pure javascript only, since javascript is synchronous by nature.
jscheuer1
12-03-2016, 12:49 AM
That was pure javascript. And I know you don't like AJAX, but consider that jQuery allows one to (via AJAX) import and execute javascript. And that of course that means it can be done without jQuery, it's just a lot more complex to write and understand.
molendijk
12-03-2016, 11:06 AM
John, what I ment was that the onload in the iframe calls the execution of javascript; it's not javascript itself. If it were js in itself, then in
<iframe src="some_file.html" name="probe" onload="external_html=frames.probe.document.body.innerHTML"></iframe>
<script>
document.write(external_html)
</script>
the execution of the onload in the iframe should be synchronous: it should occur before the document.write in the subsequent script, not after it. (And as the onload happens after the document.write, the result is 'nothing').
I don't dislike Ajax. I'm just curious to know if we can simulate it with the help of an iframe (or other means).
Some time ago, I created a HttpRequest that imports external content and executes code contained in it, and a iframe-simulation of the request that does exactly what is done by the HttpRequest, see this (http://mesdomaines.nu/eendracht/include_via_ajax_or_iframe/ajax.txt) and this (http://mesdomaines.nu/eendracht/include_via_ajax_or_iframe/iframe.txt). But these scripts don't recognize code (contained in the external file) that is not explicitly marked as 'script', like <a onclick="alert('test')">test</a>. I know this issue is very well handled by the jQuery load method, but I wanted to find a solution that is not dependent on a library, just for the fun of it. That's why I was thinking of a document.write application.
jscheuer1
12-03-2016, 01:32 PM
But you can't do doc write onload without wiping out the iframe because that invariably occurs after the iframe is parsed. Well It might work sometimes, though it's hard to image the iframe loading before the page is parsed. You just need to get in all your doc writing before the page parser (browser) closes the window for parsing/writing (before document ready).
And it's really not a question of synchronous/asynchronous. It's just what I just said. You cannot doc write after doc ready without wiping stuff out.
I'd go a bit further in that the reason there's no pausing in javascript without user interaction is, because (I think at least) if there were, you could hang stupid people up indefinitely.
coothead
12-03-2016, 03:01 PM
Hi there molendijk,
check out the attachment, which gives a possible "document.write()" solution. ;)
Note that "Google" and "Opera" do not work locally but only on a server...
Uncaught DOMException:
Blocked a frame with origin "null" from accessing a cross-origin frame
Also note that "document.close()" should always be used.
It stops the window from hanging ;)
coothead
jscheuer1
12-03-2016, 03:17 PM
I thought of that, but it's not really a solution. The content is still zapped, you're just replacing it later. You would have to rewrite the entire page. At least as I understood it, the iframe was a stand in for an entire page. One could take the innerHTML of the entire page though, get rid of the load event on the iframe, then write everything including the imported content, but that seems stupid to me, and could have unforeseen consequences on complex pages.
Arie might like it though . . .
molendijk
12-03-2016, 03:40 PM
Coothead, thanks very much. But your code wipes out all content on the page (except for the iframe-content). So it is not a real solution.
Thanks anyhow.
coothead
12-03-2016, 04:05 PM
Hi there molendijk,
But your code wipes out all content on the page...
Well, I was only working with the code that you provided.
If you want a complete valid document example, then, no problem, just try version two. :D
coothead
molendijk
12-03-2016, 05:05 PM
Well, that is really something I can use. Thanks!
coothead
12-03-2016, 05:28 PM
Hi there molendijk,
I did note that there is a problem with IE11, it doesn't stop
writing the contents of the iframe. :eek:
You will need version 3 for IE11 inclusion. :D
coothead
molendijk
12-03-2016, 06:49 PM
Coothead, I can't test the script with IE11, but I'm modifying it in order to adapt it to my requirements. I'll show you the final version a soon as it is finished. Maybe the problem will be gone by then.
coothead
12-03-2016, 06:58 PM
Hi there molendijk,
I edited my last post with an IE cure. :D
coothead
molendijk
12-03-2016, 07:18 PM
Great!
jscheuer1
12-04-2016, 01:16 AM
That's what I was suggestion might 'work' here:
http://www.dynamicdrive.com/forums/showthread.php?80747-Document-write-and-pausing&p=319893#post319893
though I was not recommending it.
Playing devil's advocate - If the page has any other scripts or css in the head, and/or a head that's complex in any other way, you're faced with duplicating all of that in your doc write script (or having to doc writing more than just the body of the 'top' page). So basically this is only for simple pages. Also, forget the head for a moment, if there are other complex things going on in the body, as I said before, there could be unexpected results.
All that said, for fairly simple situations, this will likely work well, as will AJAX, which only breaks down, or has issues at least, when when pages become more complex.
One thing I would point out in this though, as far as AJAX vs doc write from an iframe goes. With the doc write scenario, you're basically forcing the browser to parse the 'top' page twice, while with AJAX, it would only need to be parsed once.
Also, there's a reason AJAX is asynchronous, the more synchronous operations you attempt to carry out that are dependent upon fetching content from the server, the more likely you may have an unrecoverable error with no way of informing the using of it.
Powered by vBulletin® Version 4.2.2 Copyright © 2021 vBulletin Solutions, Inc. All rights reserved.