Expose an inSkinPackage(uri) method on the chrome registry

NEW
Unassigned

Status

()

--
major
14 years ago
a year ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Right now XBL hand-parses chrome: URIs to determine whether a binding is a
"skin" binding.  This is highly suboptimal; the chrome URI syntax should be
opaque to XBL.  See bug 283701 for details; this bug is on providing the chrome
registry hook needed to fix that one.  I'd really like to address this in the
1.9 timeframe, and the chrome registry seems to already have all the regular
code; it just needs to expose it...
er, I meant relevant code, not regular code.  ;)
er, I meant relevant code, not regular code.  ;)

Comment 3

14 years ago
*** Bug 306110 has been marked as a duplicate of this bug. ***
Note that bug 306110 was for the seamonkey chrome registry, while this is for
the toolkit one.  If we kill both birds in this bug, that's fine with me, of course.

Comment 5

14 years ago
Well, any change will needs be made on nsI(XUL)?ChromeRegistry, so it has to be
done in both at the same time.
So basically you just want to expose nsChromeRegistry::SplitURL?
I want a method I can call to find out whether the binding is in a skin package.
 I'd prefer getting back a boolean so I don't have to know about various
provider types in case we ever change that around in any way, of course.

Comment 8

14 years ago
How about nsIChromeURI.isSkinPackage ?
> How about nsIChromeURI.isSkinPackage ?

That would probably work ok in this case.  As long as we never have to worry
about resource: URIs and so forth pointing into skin packages, that should be
enough, I guess.

Updated

11 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: nobody → startup
still sev major?  the bug it blocks is only sev=minor with no activity for 3yr
You need to log in before you can comment on or make changes to this bug.