497570 - Provide basic navigation support for contentTabType tabs

Status: RESOLVED WONTFIX

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Mark Banner (:standard8)]

Attachment: WIP

The contentTabType tabs are a good way of displaying content to the user where we don't want to go to the browser. It would be good therefore to expand our contentTabType to allow some very basic form of navigation, there are a couple of scenarios I can see here:

1) about: navigation. In bug 480533 we want to make several about: pages directly available to the user (about:rights/about:license/about:credits). Having navigation between these would make it a lot easier for the user (and avoid nasty dialogs). I think the http: links on these pages could easily be opened in Firefox we don't need navigation from there.

2) Web page navigation. The first thing that comes to mind here is the Personas Gallery. To use that gallery folks need to be able to move around within http links.

My current thoughts are to allow a selection on which protocols to support and pass the rest out to the default browser. So, for instance, we could allow just about: if we've come into the tab from Help -> About, or http: and https: if we're doing navigation for an extension.

At the moment, I have basic support for redirecting clicks back into page loads. This also includes some back/forward support via the go menu (or the [ and ] keys). See the attached patch.

I think we need possibly need to cover UI in a separate bug. I certainly do think we need options for back/forward and maybe even displaying the url and security status (even if url is read-only).

With this patch as it stands, we'll get a error on the console each time we open a new tab with browser element:

Error: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDocShellHistory.useGlobalHistory]"  nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)"  location: "JS frame :: chrome://global/content/bindings/browser.xml ::  :: line 643"  data: no]
Source File: chrome://global/content/bindings/browser.xml
Line: 647

This is caused by us not enabling places in our default build. It doesn't affect basic navigation from what I can tell, just gives us an annoying error message.

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

Just to note, I have been testing with this patch applied and here's what I found.

When I submitted a form I was prompted to remember the form details and chose to remember them.  On subsequent visits to the form I encounter very strange focus behavior that makes the form unusable. I'm getting this error in a contentTab.

Error: Cc['@mozilla.org/satchel/form-fill-controller;1'] is undefined
Source File: file:///home/clarkbw/tbsrc/obj-i686-pc-linux-gnu/mozilla/dist/bin/components/nsLoginManager.js
Line: 95

I wish I checked for errors on the first run

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

I added some notes about my example extension using this patch to bug 346220 comment #6

Comment 4

[Phil Ringnalda (:philor)]

We don't build satchel - determining whether that's because it depends on something else we don't build, depends on something (toolkit's password manager) that we used to not build but now do, or just because we didn't feel the need, is left as an exercise...

Comment 5

[Mark Banner (:standard8)]

The patch is the issue in this case, not satchel. Although if we should be including satchel now is a good question. Was it not that wallet included form fill capabilities but they were just "disabled" in TB because it didn't need them and therefore no point in having them?

Comment 6

[Mark Banner (:standard8)]

The original intention of this bug was to provide content tabs with mini-browser like controls and things like that. At a discussion a while ago we decided that we didn't want to do that - just enable it to be possible for browser elements to navigate through pages. Extensions can then pick up with whatever UI bits that they would like.

Therefore I'm closing this bug as wontfix, and will open up new ones to cover the functionality we want.