bug 588335 dealt with namespacing startup cache urls. Unfortunately that isn't enough for omnijaring startup cache in bug 562406. For that to work one needs to use an install-location-independent location scheme. Currently startup cache urls look like: jsloader:jar:file:///home/taras/firefox/omni.jar!/components/nsPlacesDBFlush.js jsloader:resource:///modules/NetworkPrioritizer.jsm jsloader:file:///home/taras/.mozilla/firefox/xxx.default/extensions/inspector@mozilla.org/components/inspector-cmdline.js This has two problems: a) startupcache location is not portable, so this entry can't be moved into omnijar b) This isn't a very good zipfile location, so this can't be easily repacked into omnijar In my prototype for bug 562406 I worked around this by hardcoding a couple of url types in order to resolve them into saner startup cache locations. Unfortunately this approach requires hardcoding every possible url type, which obviously sucks. Can anyone suggest a more general scheme that detect firefox-internal urls(ie skip addons) and rewrite them into portable ones?

The best option in my mind is to just ship with this hack until someone comes up with a better approach.

Try this. The omnijar file checking is all wrong but I know the caller doesn't clone it. I'll get that right if this patch works for you.

Comment on attachment 488387 [details] [diff] [review] Detect omnijar jars in js component loading Tried it, looks like it will work.

Use resource://gre instead of resource:///

Are these two patches alternates, or mean to go together?

(In reply to comment #8) > Are these two patches alternates, or mean to go together? together

Comment on attachment 489641 [details] [diff] [review] convert uris into zip paths skipping scheme and redundant '/'s I could probably understand what this patch was doing if I thought hard enough, but that's just an indication that SimplifyURL needs a serious doccomment.

Correct version that checks paths instead of pointers.

Hrm, I forget that that check may not be entirely safe if the omnijar path is null..

(In reply to comment #13) > Hrm, I forget that that check may not be entirely safe if the omnijar path is > null.. Nevermind, return value catches this situation.

Comment on attachment 495162 [details] [diff] [review] commented uri transformation Why are we doing this transformation for all URLs, instead of just resource: URLs? Can we constrain our behavior here to the specific case we're trying to solve, so that we don't accidentally end up mixing file: and resource: and chrome: URIs in unexpected ways? Also, the string code is very manual. Can we use nsIURL.filePath instead of manually cutting out the scheme, and use nsCString::ReplaceSubstring instead of the manual double-slash code.

Adjusted text transformations according to review comment

(In reply to comment #15) > Comment on attachment 495162 [details] [diff] [review] > commented uri transformation > > Why are we doing this transformation for all URLs, instead of just resource: > URLs? For consistency. The existing code was already prepending jsloader: to resolve ambiguities, this doesn't go much furthe. > Can we constrain our behavior here to the specific case we're trying to solve, > so that we don't accidentally end up mixing file: and resource: and chrome: > URIs in unexpected ways? Solved that by leaving the protocol in the resulting path. > > Also, the string code is very manual. Can we use nsIURL.filePath instead of > manually cutting out the scheme, and use nsCString::ReplaceSubstring instead of > the manual double-slash code. Using nsIURI.path now, no more // collapsing(appending more carefully instead).

this time with a qref

http://hg.mozilla.org/mozilla-central/rev/b664cd398cbb http://hg.mozilla.org/mozilla-central/rev/d902db23c04e