Closed Bug 415116 Opened 14 years ago Closed 14 years ago

Chrome urls not "skin" or "locale" are assumed to be "content"

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dveditz, Assigned: dveditz)

References

()

Details

(Keywords: verified1.8.1.12, verified1.8.1.13)

In nsChromeRegistry::ConvertChromeURL chrome URIs with a "provider" that is not "skin" or "locale" are assumed to be "content" and are mapped to the registered content baseURI. I haven't found any fun things to do with this but it worries me.

nsChromeRegistry::Canonify does require "content" to fixup chrome URIs that don't have a path (short forms chrome://browser/content/)
Flags: blocking1.9?
benjamin, neil: either of you know a good reason for this (like perf)? If not I'll just fix it. Haven't checked the old mozilla/rdf/chrome to see if it has the same problem, this is based on mozilla/chrome
Assignee: nobody → dveditz
I did this in the new chrome registry because it was that way in the old registry and I didn't know what would break. I'm not sure it's a big deal, so... whatever.
I rolled this fix into bug 413250.
Depends on: 413250
Fix checked in with bug 413250
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.