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

Status: VERIFIED WONTFIX

(Core :: XUL, defect, P3)

Description

[tao]

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 :-\

Comment 1

[David Hyatt]

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.

Comment 2

[Peter Trudelle]

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

Comment 3

[ckritzer (gone)]

Marking VERIFIED WONTFIX per hyatt's comments.

Comment 4

[leger]

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.