If we pushState from foo.html to bar.html and then view source, we'll be shown the source of bar.html, even though the contents of foo.html are currently being displayed. It's unclear whether this is the behavior we want. (If you select all and then view source, you're shown the source of foo.html.)

I'm not sure why this is in "tabbed browser". It's presumably a docshell bug, right?

I wasn't sure whether to file this under the thing which exhibited the behavior (view source, part of tabbed browser, maybe?), or under the thing which was causing the behavior (certainly docshell). I'll change to the latter.

For future reference, view source is "Toolkit:View Source". I hate our component "organization".

Yeah, I suspect we should show the source of the originally loaded page, rather than the "current" page. That seems to correspond the best to what people expect from view-source.

So do we want |view source| to have the behavior of |select all|, |view selection source|, except without any text selected inside the view source window? That might resolve bug 307089, e.g.

"view selection source" always serializes the current selected DOM and displays that. "view source" displays the network stream. I think we want to maintain that.

"view source" should just use the url and history entry of the actually loaded page, not whatever it is that pushState made up, no? This doesn't seem like it would be that difficult....

Do shentries stick around forever? Otherwise we could pushstate a bunch of times and expire the page's initial shentry. Also, iirc session restore doesn't save an unlimited number of shentries, so we can't be guaranteed that the original shentry will be restored.

> Do shentries stick around forever? Generally, no. However I think we should expire state objects before expiring the "real" shentry. If we don't, that's a bug. Also, I seem to recall there being provisions in the spec for throwing away all the "state" entries for the given page and going back to the page itself in the history. Did those get removed at some point? > Also, iirc session restore doesn't save an unlimited number of shentries, so > we can't be guaranteed that the original shentry will be restored. I don't know what this has to do with anything in this bug...

(from comment 7) > "view source" should just use the url and history entry of the actually > loaded page I think this is what's confusing me. Does viewing source depend on the url and history entry, or just the url? viewSource.js::viewSource() just takes a url, but maybe the shentry is needed somewhere further up the pipe.

> Does viewing source depend on the url and history entry, or just the url? The former, if you think about POST result pages. > viewSource.js::viewSource() just takes a url It also examines window.arguments directly and pulls out shentries from it as needed. See the codepath that calls gPageLoader.loadPage().

If i click source-code at Context Menu after use history.pushState, shown white screen without page html source. The my Firefox version is "Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20100101 Firefox/5.0".