556002 - document.open() and write() after parsing is complete breaks reload button - we reload new, not original document

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Michael Lang]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1042 Safari/532.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2

In firefox 3.6.2, an invocation of the javascript method document.open() is liable  to cause a duplicate history entry to be inserted into the back/forwards buttons history which in turn interfere with the function of the back button (which fails to navigate between duplicate entries).  

The specific scenario where I was able to cause this to occur was while trying to open the document object for writing of an iframe window that was dynamically added to the page.

This behavior is inconsistent with Firefox 3.5.8 which adds no new entry to the history (as expected) and has been confirmed on both Firefox 3.6 & 3.6.2

Reproducible: Always

Steps to Reproduce:
1.insert an invisible iframe into the head of your document (via jQuery: $("<iframe style='display:none' />").appendTo(head);)
2.Acquire a handle on the document object for the window of the iframe (frame[0].contentWindow.document)
3.Open the document to prepare it for writing into (document.open())

At this point, you should find an extra history item inserted into your back button's history with duplicate title & url.  Please note, this duplicate entry does NOT appear within the "Show All History" feature.
Actual Results:  
Back button history contains an extra entry which is a duplicate of the entry for the page I've loaded, and the back button refuses to navigate between those duplicate entries

Expected Results:  
No duplicate entry inserted, back button continues to function as usual

Comment 1

[Roman Rudenko]

Attachment: Minimal testcase

Comment 2

[Roman Rudenko]

Confirmed in Firefox 12.0 and Aurora 14.0a2 on OS X Lion, as well as Firefox Beta 12.0 on Android 4.0 without any iframe shenanigans. A simple delayed document.open() is enough.

Expected result: When attached testcase is fully loaded in new tab, tab history should contain only "I am new" entry.
		
Actual result: Both "I am old" and "I am new" states are present in tab history. Reload button does not actually do anything, while single back button press causes return to "I am old" state, which jumps back to "I am new" once again.

Comment 3

[Roman Rudenko]

Using document.open("text/html", "replace"); instead of document.open() prevents pre-docwrite 'I am old' history entries from being displayed. However, Reload button still fails to reload the modified testcase, and it is impossible to navigate back to an 'I am new' entry after typing in a new URL.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Nominating because Mobify says this breaks their scripts. http://www.mobify.com/ from bug 754404 comment 4

Comment 5

[Roman Rudenko]

A clarification is in order. The bug does not break Mobify scripts, but rather behaviour of Firefox back and refresh buttons on pages transformed by Mobify.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

qawanted to retest

Comment 7

[Tony Chung [:tchung]]

qawanted: assigned to Aaron to retest

Comment 8

[Aaron Train [:aaronmt]]

I get a single history-entry, and the reload button does not actually do anything, while single back button press causes return to "I am old" state, which jumps back to "I am new" once again. Running trunk (07/09).

Comment 9

[Roman Rudenko]

Aaron, when you say that you get a single history entry, are you counting the current page state? Is it actually 2 entries, one active and the other reachable via Back button?

Comment 10

[Shawn Jansepar]

This bug is still a problem for us (Mobify) and it effects our users. Are there any plans to resolve this bug in the near future?

Comment 11

[Shawn Jansepar]

Just to give this ticket an update, the back button issue has been fixed by passing "text/html", "replace" into the arguments of document.open, like this:

doc.open("text/html", "replace");

But the refresh issue is still a serious problem. Could someone please have another look at this issue and bump it up in priority? Thanks!

Comment 12

[Mike Taylor [:miketaylr]]

I wonder if this bug is related to the following issue:

Using Firefox Desktop, spoof UA as Firefox for Android and visit http://m.wired.com/ (they're using Mobify). For me the first page load is blank, I have to refresh to get the actual page.

The first load on actual F4A gets a blank page with a bit of script up top before the mobile version loads (will upload screenshot).

Comment 13

[Mike Taylor [:miketaylr]]

Attachment: m.wired.com.png

Comment 14

[Shawn Jansepar]

Interesting. This is definitely new behaviour. I just tried accessing wired.com the same way you did on the latest Firefox for OSX by spoofing my user agent, and I did get the bit of script at the top for a split second, but then the page loads just fine. I also tried it on Firefox for Android, and it was the same - no refresh required, but I saw a bit of script at the top for a split second again. Which browser version are you using that required the refresh?

Also - it is just wired.com, not m.wired.com - Mobify does not use m. based proxy servers :)

(In reply to Mike Taylor [:miketaylr] from comment #12)
> I wonder if this bug is related to the following issue:
> 
> Using Firefox Desktop, spoof UA as Firefox for Android and visit
> http://m.wired.com/ (they're using Mobify). For me the first page load is
> blank, I have to refresh to get the actual page.
> 
> The first load on actual F4A gets a blank page with a bit of script up top
> before the mobile version loads (will upload screenshot).

Comment 15

[Mike Taylor [:miketaylr]]

(In reply to Shawn Jansepar from comment #14)
> Interesting. This is definitely new behaviour. I just tried accessing
> wired.com the same way you did on the latest Firefox for OSX by spoofing my
> user agent, and I did get the bit of script at the top for a split second,
> but then the page loads just fine. I also tried it on Firefox for Android,
> and it was the same - no refresh required, but I saw a bit of script at the
> top for a split second again. Which browser version are you using that
> required the refresh?

I was testing in Nightly (27.0a1 (2013-10-09)). Looking in the console I see: "8.877 An unbalanced tree was written using document.write() causing data from the network to be reparsed. For more information https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing".

I did the same thing in Firefox 6.0.1 (spoofing UA as Firefox for Android) and get something a little different (will attach screenshot). (In FF6, the backbutton bug is for sure a noticeable issue.)

But it seems like I'm discussing another issue that need to be filed.

Comment 16

[Mike Taylor [:miketaylr]]

Attachment: Screen Shot 2013-10-09 at 22.08.28.png

Comment 17

[Hallvord R. M. Steen [:hallvors]]

I've been discussing document.open() and history behaviour with devs recently, and they basically feel that being able to "return" to the document that created the document you're currently interacting with is a feature, not a bug - in their view, this bug as summarized is WONTFIX. For basically the same reason, reloading the document currently reloads the *new* document (as far as I can tell), i.e. the document.write() output. I suppose that could be fixed (it used to work differently in Opera, for example - it created an additional history entry, yet reloaded the original page on reload).

Comment 18

[Shawn Jansepar]

In my opinion, this is definitely not a WONTFIX. Allowing developers the ability to use document.open/document.write to create a new document, but having the new document not have the same features as the old one is wrong. In the last couple weeks we've also noticed two new bugs after using document.open/document.write that are much worse then reload being broken:

* On Firefox, links to anchors eg (<a href="#foo">) cause the browser to navigate (reload the page), because Firefox considers the re-written document to be a different location.
* The history API is no longer functional (pushState, etc are all broken)

I am planning on writing these up as separate bugs with their own test cases, but they will be very similar to the test case posted in this bug report.

Comment 19

[Hallvord R. M. Steen [:hallvors]]

If we fix the summary it will sound less "wontfixy" to the devs we need help from ;)
Bug 619092 is probably nearby, btw.

The #anchor bug is bug 881487. Please report pushState..

Comment 20

[Shawn Jansepar]

Changing the summary is a great idea :). A bit of a typo in the new summary name you've created though: should be "document.open() and write() after parsing completely breaks reload button - we reload new, not original document"

Comment 21

[Hallvord R. M. Steen [:hallvors]]

hm.. agree the new summary may be a bit ambiguous, but if you parse it as "parsing is complete" being one phrase I think it will end up correct ;-)

Comment 22

[Boris Zbarsky [:bzbarsky]]

The idea of reload (as opposed to force-reload) is generally to reload what the user sees right now.  That's why it preserves form state, etc.  So the current behavior of reloading the document-written document is very purposeful.  It'd be a pretty weird user interaction to be able to go back/forward to it (this part is required by the WHATWG spec, btw) but not to be able to reload it...

Comment 23

[Hallvord R. M. Steen [:hallvors]]

IMO the semantics of "reload" is "get me the latest and greatest from the server"..?

Comment 24

[Hallvord R. M. Steen [:hallvors]]

See also https://github.com/mobify/mobifyjs/issues/121

Comment 25

[Boris Zbarsky [:bzbarsky]]

> IMO the semantics of "reload" is "get me the latest and greatest from the server"..?

No, that's what a force-reload does.  A normal reload will hit the cache, etc.

Comment 26

[Shawn Jansepar]

The bug we've recorded also completely breaks force-reload. We were able to fix the "back/forward" issues we were having by passing ("text/html", "replace") to document.open.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Right now force-reload also reloads the actually-written document, because from the user's point of view there is no difference between a new document created via document.open and clicking on a link...  That behavior dates back to early Netscape versions, actually, and is the original way document.open was designed to work.

Comment 28

[Shawn Jansepar]

What if Firefox had an optional parameter that made document.open behave the same way other browsers do? It would maintain backwards compatibility for users who depend on this behaviour, but would allow us to fix this issue.

Comment 29

[Boris Zbarsky [:bzbarsky]]

I'd like to understand what the use cases are for having something that acts just like a link traversal for purposes of history but doesn't act the same way when reloading...  That is, what are you doing, exactly?

Comment 30

[Hallvord R. M. Steen [:hallvors]]

> because from the user's point of view there is no difference between a new document created via
> document.open and clicking on a link...

I disagree. From a user's point of view, seeing the same content after clicking reload for sites you know get updated (news sites++) is confusing. Or, looking at it from another angle: why should we allow scripts to mess with how "reload" works??

> That is, what are you doing, exactly?

Mobify uses document.open() and document.write() to overwrite the current document with one adapted to your screen size/device. The intention is to make content adaptation as simple as just adding an extra external script.

Now, one of the challenges of doing that is speculative parsing and such features - browsers eagerly try to grab all external resources they think the page will need, which wastes bandwidth and slows things down on mobile connections. The method Mobify has ended up implementing is a two-step trick:

1) First they do 
document.write('<plaintext style="display:none">')
to "neutralize" the rest of the page so that the browser doesn't try to load anything

2) On DOMContentLoaded, they extract the markup from the PLAINTEXT element, do required reformatting, and finally call document.write() again to overwrite the PLAINTEXT-mangled page with the final markup.

I'm sure this heavy document.write() usage makes your forehead hit the nearest available palm, but fact is this approach seems to work pretty well with most competitor browsers. We're being weird in ways that make the user experience worse - since an important site like wired.com deploys Mobify, this is a real problem.

Comment 31

[Sean Hogan]

(In reply to Boris Zbarsky [:bz] from comment #27)
> Right now force-reload also reloads the actually-written document, because
> from the user's point of view there is no difference between a new document
> created via document.open and clicking on a link...  

This doesn't sound right to me. If the document.open/write() isn't user-initiated and doesn't change the URL in the address bar, how is this the same as clicking on a link? 

FWIW, Webkit/Chrome behavior matches this perspective so that document.open() doesn't even append a state to history. 

Even if document.open() is conceptually the same as clicking on a link, what about for document.open('text/html', 'replace')? 

I can't think of a use-case for this second invocation except for **something like** what Mobify is doing. 

Since the "open & write with replace" can't be equivalent to a link traversal, the address-bar URL isn't changed, and no state has been appended to history, it seems reasonable that when the user tries to reload or force-reload they are assuming this is for the page for which they *did* initiate loading. 

What would happen if - after "open & write with replace" - the reload and force-reload actions ignored the written page and always loaded from the server (or cache if not-modified)? If the page hasn't been modified then the same scripts will run, doc.open/write() will be called again and the result will be exactly the same as what was written previously. If the page has been modified then the user gets the the modified page (which will probably call doc.open/write too). I think both of these outcomes are what the user would expect. 

Having said all that, I think it would be okay for Firefox to keep it's current behavior if the following worked:

    var url = document.URL;
    document.open('text/html', 'replace');
    document.write(someMarkup);
    document.close();
    history.replaceState(null, '', url);


Currently the replaceState() throws for non-null url. 
It shouldn't throw and it should dump the wyciwyg: state so that reload and force-reload have to go back to the server.

Comment 32

[Boris Zbarsky [:bzbarsky]]

> why should we allow scripts to mess with how "reload" works??

How is document.open() rewriting a document qualitatively different from loading a data: URI?

> Mobify uses document.open() and document.write() to overwrite the current
> document with one adapted to your screen size/device.

Ugh.  It sounds like they basically assumed the WebKit implementation of open/write (which doesn't add anything to history, etc) when designing this.  :(

Can we just get them to switch to a sane setup instead?

Comment 33

[Boris Zbarsky [:bzbarsky]]

> how is this the same as clicking on a link? 

It loads new content and adds a history entry.  If it's not user-initiated, it's like a location.href set, not a link click, but the result is the same.  The not changing the URL is a bit weird, I agree...

> what about for document.open('text/html', 'replace')? 

Just like location.replace().  Would you expect a reload after location.replace() to reload the new document or the old one?

We should definitely fix replaceState!  Is there a bug reported on that already?

Comment 34

[Sean Hogan]

(In reply to Boris Zbarsky [:bz] from comment #33)
> > what about for document.open('text/html', 'replace')? 
> 
> Just like location.replace().  Would you expect a reload after
> location.replace() to reload the new document or the old one?

I would expect it to reload the `url` in location.replace(url). 
Translating this to the case of document.open('text/html', 'replace') that would mean the url in the address bar.

Comment 35

[Boris Zbarsky [:bzbarsky]]

> I would expect it to reload the `url` in location.replace(url). 

What would you expect to happen when reloading a srcdoc iframe?

Comment 36

[Sean Hogan]

(In reply to Boris Zbarsky [:bz] from comment #35)
> > I would expect it to reload the `url` in location.replace(url). 
> 
> What would you expect to happen when reloading a srcdoc iframe?

From my point of view that isn't related. 

The report for the history.pushState/replaceState() exception after document.open() is at https://bugzilla.mozilla.org/show_bug.cgi?id=957479.

Comment 37

[Boris Zbarsky [:bzbarsky]]

> From my point of view that isn't related. 

Why not?  In both cases you're creating a new DOM, with associated history entry, from a string...  Note that WebKit's handling of scrdoc reloads is just as borked, btw: it just fails to reload them properly.

Comment 38

[Shawn Jansepar]

> Ugh.  It sounds like they basically assumed the WebKit implementation of open/write (which doesn't add anything to history, etc) when designing this.  :(

Correct me if I'm wrong, but when using "document.open('text/html', 'replace')", I believe Firefox also does not add anything to the history? Adding those arguments to document.write solved the back button issue we were having in Firefox.

> Can we just get them to switch to a sane setup instead?

If you have an alternative way of doing what we need, I would to have a chat :). Essentially, we need the ability to control resource loading on the page, and today we do this by using plaintext to stop resources on the page from downloading, and then we re-render the page using document.open/document.write because that is the only way to render a string of HTML in such a way that guarantees script execution order (AFAIK).

Another big issue is that after doing document.open/document.write, any links where the href is set to a hash link will cause the page to reload (unless e.preventDefault() is called). I'm guessing this is because Firefox considers the re-written document to be a different location. Should I file that as a separate bug?

Comment 39

[Boris Zbarsky [:bzbarsky]]

> I believe Firefox also does not add anything to the history? 

It does.  It adds a new history entry, which replaces the one that used to be there.  Just like location.replace() works, or navigation before end of load, etc.

> because that is the only way to render a string of HTML in such a way that guarantees
> script execution order

Hmm.  I'd been going to suggest creating a contextual fragment and then inserting it, but you're right that the script execution order is a problem there.  Henri, are there any better solutions here than document.open()?  I thought there were some in the plans, at least; maybe we should up the priority of implementing them...

> Should I file that as a separate bug?

It's already filed, as Hallvord pointed out above: bug 881487.  I'll make sure it gets fixed.

Comment 40

[Boris Zbarsky [:bzbarsky]]

Totally forgot to actually needinfo Henri.  Please see comment 39?

Comment 41

[Shawn Jansepar]

> It's already filed, as Hallvord pointed out above: bug 881487.  I'll make sure it gets fixed.

Ah, that's right - thanks!

> Henri, are there any better solutions here than document.open()?  I thought there were some in the plans, at least; maybe we should up the priority of implementing them...

If there was a better solution here I would welcome that with open arms - I'm sure many other developers would too :)

Comment 42

[Hallvord R. M. Steen [:hallvors]]

(In reply to Boris Zbarsky [:bz] from comment #32)
> > why should we allow scripts to mess with how "reload" works??
> 
> How is document.open() rewriting a document qualitatively different from
> loading a data: URI?

When you look at it from a coding perspective, it may seem similar, I get that - however, if you look at it from a user expectation perspective, the content that created the current page came from an online origin, and the user is aware of it coming from that origin and possibly getting updated. This makes a difference compared to a data: URL. So if a user clicks "reload" in the UI, his/her intention will usually be going back to that origin and asking for the latest changes. To pretty much all end users, that's how they perceive the "reload" feature of a browser. 

If we violate user expectations, that's typically a bug IMO (whether or not the code makes sense according to our logical abstractions as developers). In this case, we know we're violating user expectations because the Mobify project is getting bug reports about reload not "working". Sure, this is a corner case and may have to be special-cased to behave differently from srcdoc and data: URLs and all other features where reload isn't expected to actually reload the *previous* document in the window instead of the current - if we match user expectations better and the resulting behaviour is more useful, so what? Let's add that special case!

(And if you find other solutions for Shawn it would be great too ;-) but I think it's going to be much more involved and slow - probably require standards work and such - so I would very much like to convince you to fix this issue..)

Comment 43

[Sean Hogan]

(In reply to Boris Zbarsky [:bz] from comment #39)

> > because that is the only way to render a string of HTML in such a way that guarantees
> > script execution order
> 
> Hmm.  I'd been going to suggest creating a contextual fragment and then
> inserting it, but you're right that the script execution order is a problem
> there.  

Mobify also relies on document.open() to abort the preloader initiated downloading of resources, because writing a <plaintext> into the markup has no effect on the preloader in Firefox. 

Is there a way to abort the preloader apart from document.open()?

Comment 44

[Sean Hogan]

(In reply to Boris Zbarsky [:bz] from comment #27)
> Right now force-reload also reloads the actually-written document

It does, but not in exactly the same way - document.baseURI will be a wyciwyg: URL. 

You can see this by:

1. navigate to say 
    http://cdn.mobify.com/mobifyjs/examples/capturing-picturepolyfill/index.html
2. open the web console and type "document.baseURI"
    -> http://cdn.mobify.com/mobifyjs/examples/capturing-picturepolyfill/index.html
3. reload and type "document.baseURI"
    -> http://cdn.mobify.com/mobifyjs/examples/capturing-picturepolyfill/index.html
4. force-reload and type "document.baseURI"
    -> wyciwyg://NNN/http://cdn.mobify.com/mobifyjs/examples/capturing-picturepolyfill/index.html

This difference breaks relative URLs at step #4, which results in the loss of style in the suggested test-page. 

Not sure if this counts as a different bug to the one we are discussing.

Comment 45

[Hallvord R. M. Steen [:hallvors]]

I guess that's bug 619092 - and it's only different if this is a wontfix. Fixing this the way I'm suggesting would presumably resolve 619092 and the issue you're seeing too.

Comment 46

[Sean Hogan]

(In reply to Sean Hogan from comment #43)
> (In reply to Boris Zbarsky [:bz] from comment #39)
> 
> > > because that is the only way to render a string of HTML in such a way that guarantees
> > > script execution order
> > 
> > Hmm.  I'd been going to suggest creating a contextual fragment and then
> > inserting it, but you're right that the script execution order is a problem
> > there.  
> 
> Mobify also relies on document.open() to abort the preloader initiated
> downloading of resources, because writing a <plaintext> into the markup has
> no effect on the preloader in Firefox. 
> 
> Is there a way to abort the preloader apart from document.open()?

window.stop() seems to do the job. Does that abort async scripts or dynamically inserted scripts?

Comment 47

[Boris Zbarsky [:bzbarsky]]

> because the Mobify project is getting bug reports about reload not "working".

Yes, but that's because Mobify is violating user expectations for how whole-page document.write should be used!

Comment 48

[Shawn Jansepar]

> window.stop() seems to do the job. Does that abort async scripts or dynamically inserted scripts?

Yes, it would work. It also wouldn't matter if it aborted async scripts or dynamic scripts should it? You wouldn't be executing the page until after you execute window.stop() (for Capturing) anyways. One thing to note though is that window.stop() will cancel the page from downloading too - so you'd have to wait for DOMContentLoaded before hitting window.stop() (and still would probably want <plaintext> to prevent the document from executing any scripts).

> Yes, but that's because Mobify is violating user expectations for how whole-page document.write should be used!

How so? I don't think users have *any* expectations on how whole page document.write should be used ;).

The document.open/document.write API docs are available and do not provide much insight into the details found in the discussion we're having (in regards to history entry, reload breaking, etc), which I would argue broke my expectations as a developer using these APIs.

Comment 49

[Boris Zbarsky [:bzbarsky]]

> I don't think users have *any* expectations on how whole page document.write should be
> used

_Users_ don't expect anything from it per se, because users are never doing document.open().  But they do expect things like a link click to act like a link click, whether it rewrites the whole document using open() or whether it loads a new url.  Agreed so far?

If you look at how document.open behaves historically in non-webkit browsers, it acts pretty much like a page navigation.  That's how code written before webkit appeared expects it to behave, and how it's supposed to be used: it's a way to navigate the page to a string, predating things like srcdoc and data: URIs.  WebKit implemented open() in a totally different way from that, and now we have two totally different open() behaviors, with some code (e.g. mobify) apparently expecting the WebKit behavior while other code expects the other behavior...

Comment 50

[Hallvord R. M. Steen [:hallvors]]

Sounds like it would be nice to distinguish user-triggered document.open() from non-user-triggered.. So 

<a href="javascript:document.open();document.write(...)">click here</a>

could be handled differently from 

<body onload="document.open(); document.write(...)">

However, we already have a sort of opt-in extension in the "replace" argument to document.open(). Boris, would it make sense to make "replace" have the side effect that re-load will reload the original document from server, not the document.write() content?

Comment 51

[Boris Zbarsky [:bzbarsky]]

Maybe. Olli?

Comment 52

[Shawn Jansepar]

> window.stop() seems to do the job. Does that abort async scripts or dynamically inserted scripts?

Hmmm, you could use the plaintext tag to prevent those scripts from running in the first place.

Comment 53

[Shawn Jansepar]

Boris - do you have any updates on this? I want to make sure this conversation doesn't fall by the wayside.

Comment 54

[Boris Zbarsky [:bzbarsky]]

Shawn, this is waiting on Henri and Olli's responses to the questions above.

Comment 55

[Shawn Jansepar]

Fair enough - but since I've been mostly discussing this with you and haven't chatted with Henri and Olli I was hoping you could give them a poke :). Looking forward to their responses!

Comment 56

[Olli Pettay [:smaug][[e-mail]]]

I wouldn't change document.open()/write() API. It is horrible as is, and I don't think
it is really fixable.
However reload button in browser UI could perhaps behave differently. It could remove
wyciwyg documents, and reload the original page.

Comment 57

[Hallvord R. M. Steen [:hallvors]]

This isn't really about changing the API (this argument already exists and has a specified meaning), it's more about how our reload code interacts with it.

Either reloading the original document, or reloading the original document only when the wyciwyg document replaced it (document.open(true)) would make it possible to re-load wired.com on mobile.

Comment 58

[Olli Pettay [:smaug][[e-mail]]]

If you change the meaning of the argument, that is an API change.

UI could force reloading the original window (the one before wyciwyg).

Comment 59

[Hallvord R. M. Steen [:hallvors]]

(In reply to Olli Pettay [:smaug] from comment #58)
> UI could force reloading the original window (the one before wyciwyg).

I'd prefer this, but I think bz was arguing against it earlier in this bug?

> only when the wyciwyg document replaced it (document.open(true))

(And here I meant document.open('text/html', 'replace') of course..)

Comment 60

[Henri Sivonen (:hsivonen)]

(In reply to Boris Zbarsky [:bz] from comment #39)
> Hmm.  I'd been going to suggest creating a contextual fragment and then
> inserting it, but you're right that the script execution order is a problem
> there.  Henri, are there any better solutions here than document.open()?  I
> thought there were some in the plans, at least; maybe we should up the
> priority of implementing them...

Not sure if it's "better", but we do have a way of enforcing the execution order of script-inserted external scripts with each other: https://hsivonen.fi/script-execution/ (Script-inserted inline scripts always are run in order relative to each other.)

However, we don't have a way to emulate document.write()-like ordering of an interleaving of both script-inserted inline scripts and script-inserted external scripts with createContextualFragment. 

As for the reload button, I still think we should get rid of wyciwyg channels and make reloading document.open()ed docs work as in WebKit/Blink: re-fetching the URL in the URL bar.

(Sorry about the ridiculous delay.)

Comment 61

[Hallvord R. M. Steen [:hallvors]]

Olli/Henri: thanks for commenting - personally I would agree with you (and with comment 31), but I'm not sure if you saw and considered bz's argument against changing the implementation. Basically, document.open()/write() can be called in response to a user-initiated action, or a non-user-initated event, and making "Reload" get original document makes sense only for one of them. Consider:

1) <a href="javascript:document.open();document.write('Hello click')">click here</a>

versus

2) <body onload="document.open(); document.write('Hello load')">

In case 1), from the user's perspective I've followed a link from base document to a "Hello click" document. If I reload and have to click the same link again, that's confusing.

In case 2), as a user I'm entirely unaware that the page I just loaded did some trickery to create two history entries rather than one. If I re-load it's probably because I want to see what's new on the web site. Re-loading the wyciwyg: document with no functional way to actually update the page from the server is confusing.

Gecko's implementation suits case 1, WebKit's suits case 2. Options:

a) Decide that we consider case 1 more common or important, stick to our guns
b) Decide that we consider case 2 more common or important, go with WebKit's implementation
c) Decide that we want to distinguish the two cases and behave differently.
  c1) Apply user-initiated logic, re-load base document for non-user-initiated wyciwyg: documents
  c2) Let scripts opt-in to the "re-load base document" behaviour, for example by extending the meaning of the "replace" argument to cover this aspect too.

Personally, I have rarely seen <a href="javascript:document.write()"> (although I have written and seen <a href="javascript:frameFoo.document.write()">-solutions), and my gut feeling is that case 2 vastly outnumbers case 1 in real-life usage. Hence, I'd vote for going with WebKit but I can quite happily live with either c1 or c2 too.

Comment 62

[Olli Pettay [:smaug][[e-mail]]]

So if we made UI initiated reload to reload the original page, only the probably more rarely
used (1) would behave a bit oddly, though, not too badly.

Comment 63

[Henri Sivonen (:hsivonen)]

I'm not basing my opinion on which case is more common. I'm basing it on minimizing implementation and Web compat complications. Further, I think the chances of WebKit and Blink adopting our behavior is virtually zero.

Note that case #1 is further split into subcases:
 a) The document.written document loads scripts that do further document.writes.
 b) The document.written document doesn't do further document.writes into itself (as in your example).

Wyciwyg channels work for 1b but fail for 1a. One might argue that 1a is rare but still our current solution doesn't even properly cover all subcases of case 1.

I still think we should do the WebKit/Blink thing.

Comment 64

[Hallvord R. M. Steen [:hallvors]]

Quiet here recently :)

+1 to what Henri said. Let me also add that our current implementation comes with a very poor debugging experience. Developers who debug expect to be able to change things on the server and re-load to see the new stuff run. Breaking that expectation can lead to much head scratching..