Open Bug 36054 Opened 21 years ago Updated 3 years ago

nsNavHistory::CanAddURI() hardcodes URL schema knowledge.

Categories

(Toolkit :: Places, defect, P3)

defect

Tracking

()

ASSIGNED

People

(Reporter: bruce, Assigned: alecf)

Details

(Keywords: embed, topembed-)

NS_IMETHODIMP nsDocShell::ShouldAddToGlobalHistory(nsIURI* aURI, PRBool*
aShouldAdd) centralizes all of the decision making for the process of deciding
whether or not some URL type should be added to the global history.  Should
someone else come along and add a new type of URL, they have no means to decide
for themselves whether or not they want their URL type to be added to the Global
History unless they replace the nsDocShell with their own version.
At the same time we might want to say that action should be up to the embedder,
not the URI provider.
This kind of hardcoding was a source of maintenance and even security woes in 
MozillaClassic.  How about we get the list from some configuration file, or at 
least allow supplementing of a hardwired list from such a resource?  Cc'ing the 
W-men for their resource/file expertise.

/be
I understand the design issue here, but I don't know the (current) rules about 
which urls get added to history and which don't. Can someone state them?
-> jud
Assignee: travis → valeski
Keywords: embed
Target Milestone: --- → M19
I'm thinking this piggybacks wherever the session history exposure stuff gets
exposed (current thinking based on porkjockey's notes is nsIWebNavigation).

nsIWebNavigation::Set|GetHistorySchemes(in|out wstring schemes);
Target Milestone: M19 → mozilla0.9
travis is no longer @netscape.com
changing qa contact to default for this component
QA Contact: travis → adamlock
over to alec.
Assignee: valeski → alecf
coolness, I've been wondering about this.
Status: NEW → ASSIGNED
Bumping off the mozilla0.9 train. If this needs to be in for mozilla0.9, please 
nominate nsbeta1. Right now, it's something on the radar that I'm not sure Alec 
is going to fix for 0.9. (At least, he hasn't told me so)
Target Milestone: mozilla0.9 → ---
Target Milestone: --- → mozilla1.0
nav triage team;

Sounds fairly straightforward to do, but not a high priority for nav team.
Pushing out to mozilla1.2
Target Milestone: mozilla1.0 → mozilla1.2
Keywords: embedtopembed
Keywords: topembedembed, topembed-
Target Milestone: mozilla1.2alpha → Future

*** This bug has been marked as a duplicate of 36867 ***
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
not a duplicate - I'm dumb.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Keywords: topembed-topembed+
Status: REOPENED → ASSIGNED
Target Milestone: Future → mozilla1.4alpha
mass moving lower risk 1.4alpha stuff to 1.4beta
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Target Milestone: mozilla1.4beta → mozilla1.5alpha
5/5 EDT triage: minusing topembed+ status.  Dropping this from the radar to
better focus on existing working set.
Keywords: topembed+topembed-
adjusting summary - code moved to nsGlobalHistory::AddURI in Bug 224829
Summary: nsDocShell::ShouldAddToGlobalHistory() hardcodes URL schema knowledge. → nsGlobalHistory::AddURI() hardcodes URL schema knowledge.
QA Contact: adamlock → docshell
Target Milestone: mozilla1.5alpha → ---
nsGlobalHistory::AddURI -> nsNavHistory::CanAddURI

I think Firefox/XULRunner should accept "imap" and "news" on history, if someone (a 3rd party developer) implemented those protocol handlers. Probably it won't conflict with SeaMonkey and Thunderbird.
Component: Document Navigation → History: Global
QA Contact: docshell → history.global
Summary: nsGlobalHistory::AddURI() hardcodes URL schema knowledge. → nsNavHistory::CanAddURI() hardcodes URL schema knowledge.
Component: History: Global → Places
Product: Core → Toolkit
You need to log in before you can comment on or make changes to this bug.