548483 - Opening a link in view-source replaces current page without ability to go back

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

View-source in 1.9.2 makes all links live.  Unfortunately, the behavior is that clicking a link opens the linked source in the same {tab|window}, replacing the contents of the first item's source.

In normal view-source {tabs|windows}, Back/Forward toolbar items, main menu items, and context menu items (that are silly to be there, but…) are all disabled, so after clicking on a link, you can't go back.

In addition, there are the following bizarre behaviors:

1) When view-source is in a window, cmd-clicking a link opens the link's source view in a new tab in the same source window (which shouldn't be allowed, since it's a chrome window).

2) If I manually enter view-source:http://foo.example.com/ (rather than opening view-source using the keyboard/menu or toolbar) into a regular {tab|window}'s location bar, Back/Forward do work.

Probably the simplest solution here is to remove Back and Forward from the list of things that are disabled for view-source; people could use the main menu commands or the context menu items to go Back in a source window, or those and the toolbar items in a source tab (and make item 2 not seem so odd).

Not sure what to do about oddness item 1; dunno if we can force a new source window in that case?

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #0)
> Probably the simplest solution here is to remove Back and Forward from the list
> of things that are disabled for view-source; people could use the main menu
> commands or the context menu items to go Back in a source window, or those and
> the toolbar items in a source tab (and make item 2 not seem so odd).

Unfortunately, we validate back and forward via |canGoBack| and |canGoForward| in CHBrowserView, and those call a Core function (which apparently thinks we can't go back).  I don't know if that's a Core bug or not, but even if it is, I doubt it's one we can get fixed.

I don't know if we can insert a hack in the validation that special-cases for view-source: and does some sort of "manual" checking to see if there's a page before or after in session history.

> Not sure what to do about oddness item 1; dunno if we can force a new source
> window in that case?

ContentClickListener maybe?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Actually, since

> 2) If I manually enter view-source:http://foo.example.com/ (rather than opening
> view-source using the keyboard/menu or toolbar) into a regular {tab|window}'s
> location bar, Back/Forward do work.

works (meaning view-source: URIs do get added to session history), maybe we need to do something to force the initialization of session history in that tab/window before loading view-source and/or force v-s into that tab/window's session history.

I'm not sure we can do that, either, though; it might be all Core, but it's another avenue to explore.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Stuart said at one point in a bug that I don't have readily available now that we have several places[1] where we |[[BrowserWindowController alloc] initWithWindowNibName:@"BrowserWindow"]| instead of going through our window-opening methods that set things up for us correctly, and view-source in window is one of those places (loadSourceForFrame:inBackground:).

It's possible that if we switched things around to have that method do the right thing, we might get history inited (if it loads about:blank and then the source).  Or, we may just end up hitting bug 252653; dunno.  But that's another avenue to investigate.

[1] http://mxr.mozilla.org/camino/search?string=initWithWindowNibName%3A%40%22BrowserWindow%22%5D&find=&findi=&filter=&hitlimit=&tree=camino

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #3)
> Stuart said at one point in a bug that I don't have readily available now
> that we have several places[1] where we |[[BrowserWindowController alloc]
> initWithWindowNibName:@"BrowserWindow"]| instead of going through our
> window-opening methods that set things up for us correctly, and view-source
> in window is one of those places (loadSourceForFrame:inBackground:).

Bug 478077 comment 4, but it's not clear whether switching those would get us what we wanted here (about:blank/session history).