Closed Bug 246209 Opened 21 years ago Closed 20 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: 20 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.