324860 - chrome.manifest install fails with mixed case packagename

Status: RESOLVED DUPLICATE of bug 132183

(Toolkit :: Add-ons Manager, defect)

Description

[Martimus8]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

chrome.manifest packagename can not contain upper case letters, otherwise package never fully gets installed. packagename is unspecified in all documentation regarding case sensitivity requirements.

This includes any skin element and locale.

Further reference:
SETUP
  https://bugzilla.mozilla.org/show_bug.cgi?id=257155
  http://kb.mozillazine.org/Localize_extension_descriptions
  http://developer.mozilla.org/en/docs/Chrome_Manifest
FORUM
  http://forums.mozillazine.org/viewtopic.php?t=371375
  http://forums.mozillazine.org/viewtopic.php?t=262169

Reproducible: Always

Steps to Reproduce:
1.Start out with a "clean" firefox installation profile (or "dirty") then create an install.rdf, and reference <em:iconURL>chrome://packageName/skin/icon.png</em:iconURL>
2.create a chrome.manifest with
overlay chrome://browser/content/browser.xul chrome://packageName/content/overlay.xul

content packageName chrome/content/
locale packageName en-US chrome/locale/en-US/
skin packageName classic/1.0 chrome/skin/classic/1.0/
3. Install the package, and items do NOT load into browser

Actual Results:  
<em:iconURL> doesn't load custom 32x32 image in install.rdf and loads green puzzle piece instead in the extension manager
<em:description> doesn't load via bug 257155 work-around

Expected Results:  
packagename should be case sensitive and documented well as far as case sensitivity.


packageName
packagename
PACKAGENAME

These should all be valid, unique package names since prefs( and other objects in an extension allow all lower case, all upper case and mixed cased scenarios.

Comment 1

[Benjamin Smedberg]

*** This bug has been marked as a duplicate of 132183 ***

Comment 2

[Martimus8]

Thank you for the quick response...although I might add the duplicate didn't come up on my last search query. :)

Also normalizing the packagename to lowercase is not really a solution as URL naming conventions allow for mixed case.

Comment 3

[Benjamin Smedberg]

The standard behavior of URLs is to make the provider non-case-sensitive (this is because DNS is not case-sensitive). Chrome providers don't match up to DNS, but there is good precedent for the decision.

Comment 4

[Martimus8]

(In reply to comment #3)
> The standard behavior of URLs is to make the provider non-case-sensitive (this
> is because DNS is not case-sensitive). Chrome providers don't match up to DNS,
> but there is good precedent for the decision.
> 

I understand that is the current case...however RFC 1034 of the URL naming convention states as follows:
"...By convention, domain names can be stored with arbitrary case, but
domain name comparisons for all present domain functions are done in a
case-insensitive manner, assuming an ASCII character set, and a high
order zero bit.  This means that you are free to create a node with
label "A" or a node with label "a", but not both as brothers; you could
refer to either using "a" or "A".  When you receive a domain name or
label, you should preserve its case.  The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed..."

Why not make Mozilla products effectively take this to the next level and support it?  The chrome:// URI is something that could easily add case sensitivity to the URL parser and it would make coding much more readable to the human eye AND be consistent with all the objects available in the chrome registry.

At minimal, if Mozilla founders do decide on normalizing to lowercase, it REALLY needs to be documented in the tutorials for the current public release.

Anyhow...thanks for the interaction...I'll just have to develop around this feature.

Comment 5

[Boris Zbarsky [:bzbarsky]]

We should certainly document this, at least...