Closed Bug 246209 Opened 20 years ago Closed 19 years ago

chrome.rdf should use relative jar locations

Categories

(Toolkit :: Startup and Profile System, enhancement)

Product:
Toolkit
Component:
Startup and Profile System
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8final

People

(Reporter: bugzilla, Assigned: benjamin)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

The new profile manager command line abilities allow relative locations for
profiles to be used. This takes Firefox profiles closer to being OS independent
and would allow Firefox to be run from a USB Pen Drive easily (since absolute
paths are not required, nor is a drive letter).

However, although the profile creation works fine, extensions (and presumably
themes - which are possibly covered by another bug) use absolute locations to
the jar files in chrome.rdf, example:

c:baseURL="jar:file:///C:/Desktop/Branch20040531/profile/extensions/GUID/chrome/package.jar!/content/package/"

Changing this value to a relative location works great:
c:baseURL="jar:resource:/profile/extensions/GUID/chrome/package.jar!content/package/"

Please can we do this by default for 1.0?

Reproducible: Always
Steps to Reproduce:
Flags: blocking1.0?
Sorry for bugspam... I somehow excluded a forward slash in the second location,
after "jar!". This was my mistake, and should still be included. Only the start
of the location changed... "jar:file:///C:/Desktop/Branch20040531" to
"jar:resource:".
I would very much like to see this as well.
Oh, I'm an idiot.

resource:/ works fine, if as I have done, you've placed your profile inside the
Firefox installation directory... however it will not work for anything outside
of it.

How about simply providing relative support in the form of:
c:baseURL="jar:file:///../extensions/GUID/chrome/package.jar!/content/package/",
since the profile chrome and extension folders should always be relative to each
other.
I can confirm that this is an issue with current builds.  As to using this with
a USB key drive, the technique and reasons for doing it are explained in this
mozillaZine thread:

http://forums.mozillazine.org/viewtopic.php?t=81759

A test package is available on my website:
http://johnhaller.com/jh/mozilla/portable_firefox/

This is an admirable goal, but there are serious technical challenges:

jar:file:///../extensions/GUID/chrome/package.jar!/content/package/
is not a valid URI. The "correct" URI would probably be:
jar:../extensions/<GUID>/chrome/package.jar!/content/package/

But I don't know whether the JAR protocol handler understands that non-absolute
syntax. Furthermore, the RDF API doesn't handle relative URIs, since this arc is
an untyped literal, not a resource (a typed-literal might be best, but RDF
doesn't support that yet).

This is not going to block 1.0, but if someone creates a patch and/or I find
some free time (unlikely) I will consider landing it.
Flags: blocking1.0? → blocking1.0-
> jar:../extensions/<GUID>/chrome/package.jar!/content/package/

This may indeed be supported.  Boris added code to nsJARURI::Resolve that
appears to support this syntax.  See bug 224797.
Same issue for the Seamonkey is bug 172062.

I'd like to toss an idea around. Would it be better if there were some run-time
expandable constants in chrome.rdf ala enviroment-type variables on Windows? For
instance, %profile% constant would be expanded to profile directory location,
and %app_dir% would be expanded to program directory. Same idea can be used for
other types of URIs as well.
(In reply to comment #7)
> Same issue for the Seamonkey is bug 172062.
> 
> I'd like to toss an idea around. Would it be better if there were some run-time
> expandable constants in chrome.rdf ala enviroment-type variables on Windows? For
> instance, %profile% constant would be expanded to profile directory location,
> and %app_dir% would be expanded to program directory. Same idea can be used for
> other types of URIs as well.

One way to do that would be to have x-moz-profile and x-moz-app-dir protocols.
I don't see us supporting something like environment vars without great hassle.
> One way to do that would be to have x-moz-profile and x-moz-app-dir protocols.
> I don't see us supporting something like environment vars without great hassle.

resource://profile/foo
resource://app-dir/bar

these are also possibilities.  you can configure the resource: protocol handler
to append "foo" or "bar" onto the end of any base URI you like.

so, perhaps:

  jar:../extensions/<GUID>/chrome/package.jar!/content/package/

could be written like:

  jar:resource://extensions/<GUID>/chrome/package.jar!/content/package/

right?
resource: URIs are the way to go. resource://app-dir/ already exists (otherwise
known as resource:///) I discussed resource://profile/ with dveditz, and we
agreed that it was an unnecessary security risk. To avoid security
over-exposure, we should limit the protocol to the profile/extensions directory,
like so:

resource://profile-extensions/

perhaps, for parallelism and ease of maintenance in the EM code, a matching
resource://app-extensions/ mapping is in order.
sounds good to me.
Should searchplugins dir be also defined:

resource://app-searchplugins/

Or are there plans to merge searchplugins into extension mechanism?
This would be nice in making favicons permanent as well.  When a location is
bookmarked the cache file could be moved into an icon folder and the iconURL in
the bookmark rdf could be made a resource url.
*** Bug 250733 has been marked as a duplicate of this bug. ***
Can this be reconsidered for 1.0? According to comment 6 and comment 10, there
seems to be a viable way of doing this. It would greatly facilitate the
installation of Firefox (with extensions) on USB memory keys.

Re: comment 13:
http://bugzilla.mozilla.org/show_bug.cgi?id=174265#c74
Bug 174265 comment 74 is about a patch proposed by vladimir@pobox.com that
(according to him) should resolve the Favicon persistence bug.
> Can this be reconsidered for 1.0? According to comment 6 and comment 10, there
> seems to be a viable way of doing this. It would greatly facilitate the
> installation of Firefox (with extensions) on USB memory keys.

If someone makes a patch, I'll review it. This does not block 1.0 and I don't
have the time to do a patch before 1.0.
I'd certainly consider having a go in a week or so... I can't guarantee that I'm
up to it or that I'll have any idea what I'm doing, but I'm not an entirely
useless programmer, so if you can give me a point in the right direction (i.e.
where to start) I'll pop a comment back later if I have any success or give up. :)
Ben,  It looks to me like the resource urls are defined here:
http://lxr.mozilla.org/mozilla/source/netwerk/protocol/res/src/nsResProtocolHandler.cpp#145

I just took a look around LXR... I'm not going to be up to this. If anyone can
whip something up before 1.0, it'd be highly appreciated. From what I can
gather, this doesn't need a lot of coding, just good knowledge.
Just a question... after this is solved, will we be able to simply copy, move
and share FF profiles by manipulating the directories? (and eventually updating
profile.ini?)

I find this is extremely useful for evangelization. I hate showing a perfect
feature-packed FF to my friends and leaving them to download the bare version.
They end up saying they can't do the things I showed them before.

So, the question is, will this bug be sufficient, or will there be more work
left to be done for this to be possible (for instance, removing other absolute
paths from other files in the profile)?
Depends on: 278262
Depends on: 278534
Fixed by the patch to bug 278534.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.