645549 - FF4 App Tab URLs should act more like Bookmarks, and not be current-page persistent across restarts

Status: RESOLVED INVALID

(Firefox :: Tabbed Browser, enhancement)

Description

[K. Adams]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

If you create an App Tab, then follow a link **within** the web page loaded by that App Tab, then close/restart the browser, the App Tab loads with the most recent page opened **within** that App Tab prior to the browser being closed.

This is counter-intuitive (especially for web sites that require logins, but don't handle session expirations/login redirects well).

App Tabs should behave more like Bookmarks.  In other words, the App Tab's URL should be "locked" when defined, and should not be set to the "current" page/URL being displayed within that App Tab when the browser is closed.


Reproducible: Always

Steps to Reproduce:
1.  Open a web site; e.g. http://www.theregister.co.uk/  (the "base" home page).

2.  Pin "The Register" as an App Tab.

3.  Follow (click on) a link to one of the articles presented on "The Register" home page.

4.  Completely close Firefox.

5.  Re-open Firefox.

Actual Results:  
Unexpected/Incorrect Result:  Firefox displays the article web page, not "The Register" home page.


Expected Results:  
Expected/Correct Result:  The App Tab should load "The Register" home page, not the page for the article.


This bug may be related to (but does not appear to be the same as) #598587.

Perhaps a Preference could be added (either globally, or on a per-App Tab basis, that allows a user to lock App Tab URLs?

Comment 1

[Siddhartha Dugar [:sdrocking]]

Duplicate of Bug 598587 ?

Comment 2

[K. Adams]

@sdrocking:  Not sure.  I took a look at Bug 598587 before I posted this bug (see my comments below the "Expected Results" section of my initial post.

Bug 598587 has to do with content loaded from an external URL (i.e., typed manually, or created via a search triggered by the search bar/widget).

This bug has to do with content that is loaded from within the App Tab itself.

There is definitely some overlap there, but I'm not sure exactly where, or how much.

Comment 4

[anthonydam]

Please mark this as a suggestion.

Comment 5

[K. Adams]

This problem still exists under Firefox 6:

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0

Comment 6

[Stephan Sokolow]

Given that I see the original rationale for the current behaviour, I'd say that any solution which wouldn't make things worse for people using the thing as intended would have to support both modes of operation.

Perhaps something like an "App Tab Mode" submenu in the context menu for app tabs with radio-button menu items for these modes:
- "Allow navigation within domain"
- "Reset location on shutdown"
- "Lock location"

Comment 7

[K. Adams]

(In reply to Stephan Sokolow from comment #6)
> Perhaps something like an "App Tab Mode" submenu in the context menu for app
> tabs with radio-button menu items for these modes:
> - "Allow navigation within domain"
> - "Reset location on shutdown"
> - "Lock location"

Yes, I think giving users options controlling App Tab persistence behaviour is a great idea.

However, I'm not sure what you mean by "Allow navigation within domain".  Does that mean given an App Tab that was originally set to, for example:

-- http://www.myfakedomain-one.tld/fakelink-01

you would be allowed to navigate to any link WITHIN "myfakedomain-one.tld", but would NOT be allowed to navigate to anything on the outside, such as "myfakedomain-two.tld", and that the last-loaded page in "myfakedomain-one-tld" would be persistent across restarts?

Also, how is "Lock location" different from "Reset location on shutdown"?

Comment 8

[Stephan Sokolow]

(In reply to K. Adams from comment #7)
> However, I'm not sure what you mean by "Allow navigation within domain". 
> Does that mean given an App Tab that was originally set to, for example:
> 
> -- http://www.myfakedomain-one.tld/fakelink-01
> 
> you would be allowed to navigate to any link WITHIN "myfakedomain-one.tld",
> but would NOT be allowed to navigate to anything on the outside, such as
> "myfakedomain-two.tld", and that the last-loaded page in
> "myfakedomain-one-tld" would be persistent across restarts?
> 

Basically. Links outside "myfakedomain-one.tld" would open in a new tab when clicked while links within the domain would navigate the app tab and changes to the app tab's URL would persist across restarts.

> Also, how is "Lock location" different from "Reset location on shutdown"?

"Reset location on shutdown" would be like "Allow navigation within domain" but wouldn't persist changes to the app tab's URL across restarts. (So, if you set it on GMail and pinned the inbox, you'd be able to navigate into and out of messages, but a restart would land you back at the inbox)

"Lock location" would force EVERY link that would navigate to a new page to open in a new tab. (Useful for if you want multiple persistent "home tab"-style pages and for certain types of single-page web apps which only update the address bar hash when requested manually but don't set target="_blank" the way TiddlyWiki does)

The behaviour of the hash portion of the URL in response to those options would probably take more discussion.

As I see it, the safest GNOME-style approach (Don't over-complicate things, even if that means omitting the "Advanced Settings..." button because grannies are apparently terrified of it) would be to persist changes to the hash in all modes, since persisting state within a single-page app is less likely to cause problems than interfering with the innards of a web app that may react badly to having its links force-opened in new tabs by the browser.

However, if anyone can think of a suitably un-technical way to present it, it'd be nice to have the choices an "also apply restrictions to hash" checkbox would provide. (eg. "Reset non-hash portion but persist changes to the hash within the single-page web app" vs. "Reset everything including the hash" and "Lock URL but allow hash navigation" vs. "This single-page web-app is well-coded. Open all links (even internal ones) in new tabs."

The best I can imagine for that scenario is finding a synonym for "also apply restrictions to URL hash" that's concise and reasonably non-technical and adding a separator and checkbox in the hypothetical submenu below the three radio buttons.

Comment 9

[:Gijs (out for now; he/him)]

This was discussed with the product and UX folks and we decided not to pursue this - we think the current behaviour is effectively what people expect.