URI fixup & keyword should be moved out of docshell into a service

RESOLVED FIXED

Status

()

Core
Document Navigation
P3
normal
RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: Adam Lock, Assigned: Adam Lock)

Tracking

({embed})

Trunk
x86
Windows NT
embed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Assignee)

Description

18 years ago
Docshell & webshell perform URI fixup and keyword detection before starting 
a load. This code should be taken out of docshell and moved into a service. It 
would be desirable for this service to be a Javascript object to allow people to 
customise it's behaviour, e.g. use a different keyword lookup service, fixup 
custom URIs, localized fixup - www.blah.co.jp instead of www.blah.com etc.
(Assignee)

Comment 1

18 years ago
Created attachment 17633 [details] [diff] [review]
Docshell with keyword stuff removed
(Assignee)

Comment 2

18 years ago
Created attachment 17634 [details]
New URI fixup interface
(Assignee)

Comment 3

18 years ago
Created attachment 17635 [details]
New fixup object, the default one

Comment 4

18 years ago
suggestion: rather than having a NS_NewFoo() global function, might I suggest
that you use a default contructor so you can use the component manager for creation?
(Assignee)

Comment 5

18 years ago
That's phase 2 :)

I may make the docshell pick up the fixup object from a category and 
additionally, add a property to one of the public interfaces that allows the 
fixup object to be replaced by the client.

Updated

18 years ago
Keywords: embed
(Assignee)

Comment 6

18 years ago
Created attachment 18944 [details] [diff] [review]
Latest fixup patch makes the fixup object a global service. Submitting this one for review.
(Assignee)

Comment 7

18 years ago
Created attachment 18945 [details] [diff] [review]
Oops, try I'll try that again with a context diff

Comment 8

18 years ago
Here are my (decidedly uninformed) observations

1. Seems to me that the "URI fixup" object should be a service: my guess is that
it is an application-wide policy, right? (Or, am I wrong? Do we want to vary the
fixup that's performed on a docshell-by-docshell basis?)

2. If you agree that it should be a service, then it seems like we should move
the code that grovels through prefs into the service's implementation. In other
words, why does docshell know about "keywords"? We don't want to change docshell
the next time someone gets a wild hair up their ass about typing random crap
into the URL bar! :-) It'd be nice to just update the fixup policy...

3. If you agree with (1) and (2), then it seems like the fixup API could be a
bit narrower: "nsIURI fixup(in wstring aURIishString)". Or are the fixup flags
still necessary?

Let me know if I'm off base...
(Assignee)

Comment 9

18 years ago
Chris, in response to your points:

1. It is a service. The latest patch makes it a global service, requested for 
by each docshell via a contract.
2. Yes, the prefs code could be moved from the docshell side into the service. I 
can try and prepare a patch that does that and see if there are any issues.
Status: NEW → ASSIGNED
(Assignee)

Comment 10

18 years ago
Created attachment 18947 [details] [diff] [review]
Revised patch removes the flags parameter and the test for keyword support into the fixup service
(Assignee)

Comment 11

18 years ago
For the new patch I've moved the test for keywords support into the fixup
service and removed the flags parameter from the interface. I've also changed
docshell slightly so it calls NS_NewURI if it can't find the fixup service
(because it's not registered, compiled-in or whatever).

Comment 12

18 years ago
This looks great to me. You can count me as either r= or sr=.
(Assignee)

Comment 13

18 years ago
Thanks Chris, fix checked into trunk
(Assignee)

Comment 14

18 years ago
Marking fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.