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

RESOLVED FIXED

Status

()

Core
General
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

({verified1.8.1.12, verified1.8.1.13})

unspecified
verified1.8.1.12, verified1.8.1.13
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Assignee)

Description

10 years ago
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?
(Assignee)

Comment 1

10 years ago
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.
(Assignee)

Comment 3

10 years ago
I rolled this fix into bug 413250.
Depends on: 413250
Keywords: fixed1.8.1.12, fixed1.8.1.13
(Assignee)

Comment 4

10 years ago
Fix checked in with bug 413250
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Depends on: 417584
This was verified with bug 413250 then.
Keywords: fixed1.8.1.12, fixed1.8.1.13 → verified1.8.1.12, verified1.8.1.13
You need to log in before you can comment on or make changes to this bug.