486352 - chrome overrides do not work with query strings

Status: UNCONFIRMED

(Toolkit :: Startup and Profile System, defect)

Description

[Mook (songbird dead account)]

STR:
0. Install Console2, https://addons.mozilla.org/en-US/firefox/addon/1815
1. In the browser, go to chrome://global/content/console.xul
2. In the browser, go to chrome://global/content/console.xul?hello

Expected results:
The same page loads.

Actual results:
Different documents load, because the chrome override doesn't apply to the second URL because of the query string.

Filing unconfirmed because I haven't tested with trunk yet.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7

(Is this where the chrome manifest bugs go now? The other ones seem to be here...)

Comment 1

[Benjamin Smedberg]

overall, query strings on chrome URLs is a bad idea. I'm inclined to say we should disallow them altogether, rather than trying to cobble together support for them. Dave, thoughts?

Comment 2

[Dave Townsend [:mossop]]

You can still apply an override to "chrome://global/content/console.xul?hello" and that would work though right?

I generally agree that there probably isn't a great deal of use to query strings, however they do provide interesting ways to applying different stylesheets/overlays depending on the query string the window was opened with so I think the way it works now is probably fine. Not that I'd be bothered (or probably notice) if support for it dropped but I'm not sure we need to go to the effort to do anything beyond maybe documenting this case here.

Comment 3

[Mook (songbird dead account)]

(In reply to comment #2)
> You can still apply an override to "chrome://global/content/console.xul?hello"
> and that would work though right?
Yeah, that should still work.  Of course, since in our case the query param is dynamic, it doesn't work so well ;)

> I generally agree that there probably isn't a great deal of use to query
> strings, however they do provide interesting ways to applying different
> stylesheets/overlays depending on the query string the window was opened with
> so I think the way it works now is probably fine. Not that I'd be bothered (or
> probably notice) if support for it dropped but I'm not sure we need to go to
> the effort to do anything beyond maybe documenting this case here.

Umm, my desired outcome is to match ignoring query strings; i.e. overlaying "chrome://global/content/console.xul" should also overlay "chrome://global/content/console.xul?hello".  (See my expected results ;) )  We use them that way because doing things like bookmarking them is a lot easier when you can express the state as a string.

Comment 4

[Mike Kaply [:mkaply]]

See bug 771128.

Firefox uses parameters to display a favicon at 16x16 on the about screen:

chrome://branding/content/icon32.png#-moz-resolution=16,16

Of course those parameters are completely ignored and it still gets a 32x32, but you can't override this image with chrome.manifest