onLocationChange to wyciwyg
John J. Barton
http://code.google.com/p/fbug/issues/detail?id=2649,
I came up with a weird effect. After I completed the user's test
procedure, I tried to reload the page to start over, but I could not
succeed. The reload request causes an onLocationChange to a url,
wyciwyg://1/http://www.simpsoncrazy.com/pictures
which fails with a JS error. The tab is blank, but the location bar
still shows http://www.simpsoncrazy.com/pictures. If I exit Firefox and
restart, I get the same result: the wyciwyg content is loaded but the
location bar says something different. ( FF 3.6. but the user reports
the problem on FF 3.5).
To me the location bar is lying: if the location changes to wyciwyg:...
then that is what the location bar ought to show, No?
jjb
Boris Zbarsky
> The reload request causes an onLocationChange to a url,
> wyciwyg://1/http://www.simpsoncrazy.com/pictures
OK....
> which fails with a JS error.
Fails what where with what JS error?
> The tab is blank,
Just like it was before the reload, right?
> but the location bar still shows http://www.simpsoncrazy.com/pictures. If I exit Firefox and
> restart, I get the same result: the wyciwyg content is loaded but the
> location bar says something different.
That's correct.
> To me the location bar is lying: if the location changes to wyciwyg:...
> then that is what the location bar ought to show, No?
No. wyciwyg is an internal URI scheme used to represent document.write
result pages; the location bar shows the thing after the slash which
comes after the number which comes after wyciwig://.
See also nsIURIFixup.createExposableURI.
In your case, sounds like something Firebug does triggers a
document.write or document.open call by the page (which if done after
DOMContentLoaded will blow away the old document). You might want to
look into why exactly a write() or open() happens.
-Boris
John J. Barton
> On 1/3/10 1:07 PM, John J. Barton wrote:
>> The reload request causes an onLocationChange to a url,
>> wyciwyg://1/http://www.simpsoncrazy.com/pictures
>
> OK....
I believe the root of the Firebug problem is that we do not get a
pagehide event on http://www.simponcrazy.com when the wyciwyg page takes
over. So Firebug fails to notice that the window content has changed. I
was thrown off because the reload did not work, so I focused on that issue.
>
>> which fails with a JS error.
>
> Fails what where with what JS error?
The content of the wyciwyg page is:
<html><head><script>google_protectAndRun("ads_core.google_render_ad",
google_handleError, google_render_ad);</script></head></html>
the error is
google_protectAndRun is not defined
http://www.simpsoncrazy.com/pictures
Line 1
>
>> The tab is blank,
>
> Just like it was before the reload, right?
Correct, the content of the window is the same. So, as a user, I think I
am commanding Firefox to reload http://www.simpsoncrazy.com/pictures,
but (I guess) I am reloading the wyciwyg url? I assumed that the
location bar was accurate.
>> but the location bar still shows
>> http://www.simpsoncrazy.com/pictures. If I exit Firefox and
>> restart, I get the same result: the wyciwyg content is loaded but the
>> location bar says something different.
>
> That's correct.
I guess you mean "that is the behavior I expect from the code". I have a
hard time understanding why Firefox would show me the wyciwyg result but
the simpsoncrazy.com URL. As far as I can tell the browser is now
broken: the site fails to come up if I reload or even restart the browser.
>
>> To me the location bar is lying: if the location changes to wyciwyg:...
>> then that is what the location bar ought to show, No?
>
> No. wyciwyg is an internal URI scheme used to represent document.write
> result pages; the location bar shows the thing after the slash which
> comes after the number which comes after wyciwig://.
The location bar shows the string after the number, but the window does
not show the web page for that location.
>
> See also nsIURIFixup.createExposableURI.
But as a user I am seeing only the exposed URI. That is the only thing I
can see. So when I look at <URL> and say "reload" I can mean only one
thing: 'reload <URL>'. I can't mean "reload wyciwyg://<URL>" because I
don't know about it.
>
> In your case, sounds like something Firebug does triggers a
> document.write or document.open call by the page (which if done after
> DOMContentLoaded will blow away the old document). You might want to
> look into why exactly a write() or open() happens.
I don't believe Firebug is doing this. We've never seen this behavior
before. I guess the page is doing it, but the code is compressed. But in
any case, Firebug should track the wyciwyg page, so I need the pagehide
event to fire.
>
> -Boris
Boris Zbarsky
> I believe the root of the Firebug problem is that we do not get a
> pagehide event on http://www.simponcrazy.com when the wyciwyg page takes
> over.
Which is basically when someone does a document.open() on the document.
There is no load accompanying that, so no pagehide/show events, right...
Maybe we should fire them in this case.
> Correct, the content of the window is the same. So, as a user, I think I
> am commanding Firefox to reload http://www.simpsoncrazy.com/pictures,
> but (I guess) I am reloading the wyciwyg url?
Yes.
> I assumed that the location bar was accurate.
The location bar shows "who" the page is. In the document.write() case,
that's whoever called write().
> I guess you mean "that is the behavior I expect from the code".
No, I mean "that is the behavior users expect and that we've had all along".
> I have a hard time understanding why Firefox would show me the wyciwyg result but
> the simpsoncrazy.com URL.
Because as far as the user is concerned, that's the right URL to be
showing for document.write-generated content. That's what every single
browser has done for a good long while now (going on 15+ years).
> As far as I can tell the browser is now broken: the site fails to come up if I reload or even restart the browser.
The whole point of wyciwyg urls is to make reload of
document.write-generated content actually work. That part works fine;
note that in your case the failure is _before_ the reload.
You're correct that wyciwyg is not persisted across restart correctly;
we should probably fix that.
> The location bar shows the string after the number, but the window does
> not show the web page for that location.
What exactly is "the web page for that location"? There are plenty of
cases where that would be true; for example if someone reached in and
changed the DOM...
> But as a user I am seeing only the exposed URI.
Correct.
> That is the only thing I can see. So when I look at <URL> and say "reload" I can mean only one
> thing: 'reload <URL>'
No. When the user says "reload" they mean "reload whatever is in the
browser". They don't care what the url is, and almost never actually
think of the url.
> I don't believe Firebug is doing this.
Well, I don't see the page going blank without Firebug, and the steps to
reproduce only involve Firebug operations. So while you're almost
certainly correct that the write() comes from the page, something
Firebug does is causing the page to do that...
-Boris
John J. Barton
> On 1/4/10 11:19 AM, John J. Barton wrote:
>> I believe the root of the Firebug problem is that we do not get a
>> pagehide event on http://www.simponcrazy.com when the wyciwyg page takes
>> over.
>
> Which is basically when someone does a document.open() on the document.
> There is no load accompanying that, so no pagehide/show events, right...
>
> Maybe we should fire them in this case.
If firebug sees wyciwyg://1/<URL> can it assume that <URL> issued a
document.open()?
jjb
John J. Barton
> On 1/4/10 11:19 AM, John J. Barton wrote:
>> Correct, the content of the window is the same. So, as a user, I think I
>> am commanding Firefox to reload http://www.simpsoncrazy.com/pictures,
>> but (I guess) I am reloading the wyciwyg url?
>
> Yes.
>
>> I assumed that the location bar was accurate.
>
> The location bar shows "who" the page is. In the document.write() case,
> that's whoever called write().
>
>> I guess you mean "that is the behavior I expect from the code".
>
> No, I mean "that is the behavior users expect and that we've had all
> along".
>
>> I have a hard time understanding why Firefox would show me the wyciwyg
>> result but
>> the simpsoncrazy.com URL.
>
> Because as far as the user is concerned, that's the right URL to be
> showing for document.write-generated content. That's what every single
> browser has done for a good long while now (going on 15+ years).
Ok, so the location bar is correct, because ...
>
>> As far as I can tell the browser is now broken: the site fails to come
>> up if I reload or even restart the browser.
>
> The whole point of wyciwyg urls is to make reload of
> document.write-generated content actually work. That part works fine;
> note that in your case the failure is _before_ the reload.
...the browser thinks that the wyciwyg page is the result of loading the
page. Ok, but why doesn't Control-F5 cause the original page to reload?
I thought Control-F5 meant "reload and don't use any cache" so "what you
cache is what you get" (wyciwyg) would not be used.
>
> You're correct that wyciwyg is not persisted across restart correctly;
> we should probably fix that.
>
>> The location bar shows the string after the number, but the window does
>> not show the web page for that location.
>
> What exactly is "the web page for that location"? There are plenty of
> cases where that would be true; for example if someone reached in and
> changed the DOM...
>
>> But as a user I am seeing only the exposed URI.
>
> Correct.
>
>> That is the only thing I can see. So when I look at <URL> and say
>> "reload" I can mean only one
>> thing: 'reload <URL>'
>
> No. When the user says "reload" they mean "reload whatever is in the
> browser". They don't care what the url is, and almost never actually
> think of the url.
? This isn't making sense to me. "reload whatever is in the browser"
would be a no-op: it's already in the browser. Surely reload must mean
"re-" doing some thing such that the current state is gone and a new
state is created. I guess re-reading the cache would be ok for normal
reload, but for Cntrol-F5 I think it should start all over no?
jjb
Boris Zbarsky
> ....the browser thinks that the wyciwyg page is the result of loading
> the page.
No. The browser thinks that the wyciwyg page is the result of
generating a page entirely via document.write and that therefore
reloading it should act as if the write() calls were executed again.
> Ok, but why doesn't Control-F5 cause the original page to
> reload? I thought Control-F5 meant "reload and don't use any cache" so
> "what you cache is what you get" (wyciwyg) would not be used.
See above.
> ? This isn't making sense to me. "reload whatever is in the browser"
> would be a no-op: it's already in the browser.
Perhaps a better description is "put whatever is currently in the
browser back to its original state" or "put whatever is currently in the
browser in its up-to-date state". Unfortunately, reload means all of these.
Seriously, if you have a better suggestion for exposing
document.write-generated pages to users, please file bugs.
-Boris
Boris Zbarsky
> If firebug sees wyciwyg://1/<URL> can it assume that <URL> issued a
> document.open()?
Yes.
-Boris
John J. Barton
> On 1/4/10 12:23 PM, John J. Barton wrote:
>> ....the browser thinks that the wyciwyg page is the result of loading
>> the page.
>
> No. The browser thinks that the wyciwyg page is the result of
> generating a page entirely via document.write and that therefore
> reloading it should act as if the write() calls were executed again.
But what if the document.write() result depends on server side content?
Or depends on user actions?
>
>> Ok, but why doesn't Control-F5 cause the original page to
>> reload? I thought Control-F5 meant "reload and don't use any cache" so
>> "what you cache is what you get" (wyciwyg) would not be used.
>
> See above.
>
>> ? This isn't making sense to me. "reload whatever is in the browser"
>> would be a no-op: it's already in the browser.
>
> Perhaps a better description is "put whatever is currently in the
> browser back to its original state" or "put whatever is currently in the
> browser in its up-to-date state". Unfortunately, reload means all of
> these.
Ok but the current behavior does neither of these. Rather it seems to
load the last cached state. I agree that is often what you want with
regular reload. I don't think it is ever what you want with reload-but
-bypass-the-cache.
>
> Seriously, if you have a better suggestion for exposing
> document.write-generated pages to users, please file bugs.
But you are telling the current behavior is not a bug. If I create a
test case with server side updates or user actions then is it a bug?
jjb
John J. Barton
What do you think Firebug ought to show then? MDC says
If a document exists in the target, this method clears it
https://developer.mozilla.org/En/DOM/Document.open
but does that mean that the resulting DOM has no state from the original
page? The scripts of the original page are gone? Or just the html is
different?
I guess its just like a load and Firebug should evict the original page
info. But it means the developer has no to help connect the result to
the cause.
jjb
Boris Zbarsky
> But what if the document.write() result depends on server side content?
> Or depends on user actions?
"Too bad". More precisely, at least this way the behavior is consistent
with other browsers, so doesn't break any existing content...
> Ok but the current behavior does neither of these. Rather it seems to
> load the last cached state.
It loads precisely what I said: the state that resulted from the write()
calls in question.
There might not be anything else to reload, in fact:
var w = window.open();
w.document.write("some stuff");
Now the user reloads the tab |w| is in. What do you expect to reload,
exactly?
> But you are telling the current behavior is not a bug.
I'm saying the current behavior is quite purposeful. That doesn't mean
we can't purposefully switch to a different behavior if it turns out
that it's better and doesn't break any existing content.
-Boris
Boris Zbarsky
> https://developer.mozilla.org/En/DOM/Document.open
>
> but does that mean that the resulting DOM has no state from the original
> page?
Pretty much, yes (modulo the usual about:blank weirdness).
Specifically, the old DOM is completely removed (well, at least on
trunk), a new JS scope object is created, etc. Looks just like a
pageload "from the inside".
> I guess its just like a load and Firebug should evict the original page
> info.
Yes.
-Boris