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/)
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.
Fix checked in with bug 413250
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
This was verified with bug 413250 then.
Keywords: fixed220.127.116.11, fixed18.104.22.168 → verified22.214.171.124, verified126.96.36.199
You need to log in before you can comment on or make changes to this bug.