Closed Bug 788547 Opened 7 years ago Closed 9 months ago
URL changes to wyciwyg://N/<old URL> after document
250 bytes, text/html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: Execute document.write on a web page after the page has been fully loaded. Actual results: The contents of the page are replaced by the output of document.write, the browser starts loading (the load icon is spinning) and never stops. Upon pressing Esc, the URL bar changes to wyciwyg://N/<old URL> where N is a number. Trying to reload the page (with F5 or the circle-arrow icon) seems to have no effect, and the network tab of Firebug does not show anything at all. Expected results: The contents of the page are replaced by the output of document.write. The URL is unchanged, and reloading works as expected.
There are a number of closed old bugs which are very similar, except N is 0: https://bugzilla.mozilla.org/show_bug.cgi?id=123140 https://bugzilla.mozilla.org/show_bug.cgi?id=125225 https://bugzilla.mozilla.org/show_bug.cgi?id=204956 https://bugzilla.mozilla.org/show_bug.cgi?id=528925 https://bugzilla.mozilla.org/show_bug.cgi?id=735225 Probably not a new problem, as there are lots of reports about it, e.g. support.mozilla.org/en-US/questions/699151 http://forums.mozillazine.org/viewtopic.php?p=7485605 http://stackoverflow.com/questions/1984801/jsf-problem-with-firefox-3-5-caching-wyciwyg-prefix
> the browser starts loading (the load icon is spinning) and never stops. That's because the document is not done loading. If you make more document.write calls, they will add to the document. If the document were done loading, a document.write call would replace the document.
(In reply to Boris Zbarsky (:bz) from comment #2) > That's because the document is not done loading. document.write was called in the domready event handler. But just to be sure, I updated the test page to run document.write on click and the behavior is the same.
No, the point is that when you call write() on a document that is no longer being parsed, the document is reopened and goes back into a loading state. And it stays in that state until you call document.close().
experiencing the same behavior here. Confirmed that the document.close() solve the issue. But the bug is that it's happening on some pages (maybe they are not well written enough), but it's NOT happening with other browsers.
I've recently run into this problem (Windows 7, FF version 50.0.2. Some previous comments indicate a cause related to doing document.write(...) and indeed my app is doing that. Those comments seem to suggest that the lack of a document.close() is the culprit, but in all cases in my app, doc.write(...) is immediately followed by doc.close() so I'm still at a loss as to what our app is doing to cause this, or what workarounds might exist to prevent it. It happens with our app like clockwork (sometimes all it takes is a single click of the refresh/reload button and it happens), and never with any of the other browsers we're using to access our app (mostly IE and Chrome). Any advice would be most appreciated.
Status: UNCONFIRMED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.