Development:Planning:Internal URIs

We need to evaluate/audit/decide/whatever how special-case URIs (e.g., about:, view-source:, etc.) should be handled by various features (i.e., View Source, Save As, etc.).

about:

View Source

View Source should either be disabled for all about: URIs, or be disabled for about:bookmarks, about:history, about:credits, and about:blank. (more IRC discussion needed)

Save As

Save As should be disabled for all about: URIs.

Email Page Location

Email Page Location should be disabled for all about: URIs.

Fill Form

Fill Form should be disabled for all about: URIs.

Get Info

Get Info should probably be disabled for all about: URIs.

Set as home page

• about:blank and about:bookmarks are the only two about: URIs that make sense as a home page. Should we do something about this?

Personally, I think we should let users have whatever homepage they want. If about:plugins (or whatever) gets them off, more power to them. Froodian

I think people wanted history as their home page (one of the reasons for implementing that pseudo-URI), so about:history definitely belongs in the allowed group. Like Froodian above, I can certainly make a geeky case for others, like about:buildconfig (trying out all those opt-builders), though I'm not sure I want to make that case. sardisson

Bookmarking

• I understand the perceived need to bookmark about:bookmarks, but we should probably disable the Add Page to Bookmarks menu item for all other about: URIs. On a related note, we should disabled Add Bookmark Folder when History is active.

Same as with set home page, I think users should be able to add any about:uris (except about:blank?) to bookmarks using the Add Page to Bookmarks menu item. Froodian

Even moreso than above, I think we should allow any page to be bookmarked. sardisson

History

about: URIs should not be added to history.

Autocomplete

There seems to be no reason to have about: URIs in the autocomplete database either.

I dunno... I like being able to autocomplete from about: URIs. I know I do so frequently. Even if it only saves me a few keystrokes, it still saves me a few keystrokes. Also this might be an argument for keeping them in the History. Froodian

I like being able to autocomplete about:config, though I might not cry over not being able to do so. sardisson

Reload

We already disable reload for about:bookmarks and about:history. We should probably do the same for about:config (since all its data is updated dynamically already). Maybe for about:blank too (just 'cause it's a weird idea). All others seem fair game for reload though.

It only makes sense to have reload enabled for pages that are really external to the client (about:credits; about:licen[cs]e might be, too?). Of course, that gets back to the consistency/implementation detail issue.... :-( sardisson

Find

We should disable all find options on about:config, since they don't do anything (and we have the filter)

view-source:

View Source

View Source should be disabled when viewing source of a page. Bug 159337

Save As

Save As should be enabled when viewing the source of a page. Since this is currently the case, no action is needed on our part, except to avoid regressions as we're fixing other stuff.

Email Page Location

Email Page Location should be disabled when viewing the source of a page.

I think it's perfectly reasonable to assume that a user would want to email source to somebody else, and we should have it be enabled (unless other browsers don't use view-source:). Froodian

Two comments: Firefox doesn't allow it, and I believe the view-source: protocol is a Mozilla peculiarity. Safari doesn't recognise it, certainly. clawson 16:27, 20 June 2006 (PDT)

OK. If it's a Mozilla only (or non-safari) thing, dump it then, because having users email their friends bogus view-source links is worse than not allowing them to email them at all. Froodian 17:07, 20 June 2006 (PDT)

Fill Form

Fill Form should be disabled when viewing the source of a page.

Get Info

Get Info should probably be disabled when viewing the source of a page.

I think it's legitimate to leave it enabled in this situation. If a user doesn't know about the show/hide toolbar widget, this might be their first reaction for URL hacking a view-source page. Froodian

Set as home page

It seems a little silly to allow a view-source: page to be set as the home page.

Bookmarking

“Add Page to Bookmarks” should be disabled when view-source is in view.

I've bookmarked view-source: (or source window) pages often when working on bugs; I think it's reasonable to leave that enabled here. --sardisson

History

view-source: URIs should not be added to history.

For global history I agree (and this works now); for session history, there's Bug 252653 explicitly calling for them to be added (and isn't it a matter of us simply setting a flag, like we set flags to hide iframe URLs from global/session history?) --sardisson

Autocomplete

There seems to be no reason to have view-source: URIs in the autocomplete database either.

oddly enough, they do show up in the autocomplete database :P how is that so?

External (non-Camino-handled) protocols

They can currently be bookmarked. If this is OK, then we should probably not be adding them to the top 10 (see also Bug 302601) or history, and we may not want to keep a visit count for them. Are there other situations we should worry about with external protocols? They definitely shouldn't be autocompleted.

Other situations

• Should we be allowing users to bookmark view-source: or about: URIs?
  • If so, should we increment visit counts for them?
  • If so, should they be on the top 10 list? See also Bug 302601.

FWIW, yes, yes, no --sardisson

• data: URIs
• javascript: URIs