bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

[Configurable URL]fllling in <base> entries obsoletes <name> entries in registry

VERIFIED WONTFIX

Status

()

Core
XUL
P3
major
VERIFIED WONTFIX
19 years ago
2 years ago

People

(Reporter: tao, Assigned: David Hyatt)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Hi, David:

I was playing with chrome registry recently and found that as soon as I fill
in the <base> entries in the registry for any package, the chrome conversion
function stops using the <name> entry.

I expected that the base entries serve the purpose of bulk switching chrome
resources location. For example, with localeProvider <name>="en-US" and
<base> absent, the chrome URL, "chrome://addressbook/locale/foo.dtd",
resolves to "resource:/chrome/addressbook/locale/en-US/foo.dtd".

If I fill in the base entry with "http://www.mozillazine.org/chrome", it
resolves to "http://www.mozillazine.org/chrome/foo.dtd". I tried
"http://www.mozillazine.org/chrome/addressbook", it resolved to
"http://www.mozillazine.org/chrome/addressbook/foo.dtd"...
Only when base="http://www.mozillazine.org/chrome/addressbook/locale/en-US"
does it resolve to
"http://www.mozillazine.org/chrome/addressbook/lcoale/en-US/foo.dtd".

Looking at the chrome url conversion function, it appears that this problem
would happen to all provider types.

I thought that <base> entry shall replace the default "resource:/chrome/" only.

The current behavior make switching the chrome base directory a real pain :-\
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M15
(Assignee)

Comment 1

19 years ago
This is really low priority, since we aren't using the <base> entry internally,
and the actual higher-level chrome API will download and install the chrome.
The <base> entry is really only still around so that mozillaZine can have its
chromeZone.  Once the higher-level API comes online, <base> can completely go
away.

I'll keep it open for now.  Moving to m15.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
Summary: [Confiurable URL]fllling in <base> entries obsoletes <name> entries in registry → [Configurable URL]fllling in <base> entries obsoletes <name> entries in registry

Comment 2

19 years ago
resolving as wontfix because chrome registry will not support <base>

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 3

19 years ago
Marking VERIFIED WONTFIX per hyatt's comments.

Comment 4

19 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: ckritzer → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.