287618 - Default pref files not read with .JS extension (on CD-ROM)

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[Georg Ragaz]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: mozilla, mfcembed up to current version 1.76

The file default\all.js is not interpreted properly if not in small letters, 
i.e. if the file is capitalized such as on a CD ROM for an embedded system 
then the password manager does not show the checkmark for saving passwords. If 
the CD ROM is created with the joliet extension and js.all is in small letters 
then it works properly. The Problem can be reproduced by just changing the 
extension of all.js to all.JS then the checkbox for password saving does not 
appear anymore when logging in to a protected web site. This may not seem a 
big deal but it appears that all.js is not properly interpreted and afterwards 
I have not been able to properly log on to a php site requesting a password.

Reproducible: Always

Steps to Reproduce:
1. Normal installation on a windows system
2. Change all.js to all.JS
3. Start mfcembed or mozilla.exe
3. Attempt to log in to a site that prompts for a password. The checkbox for 
saving the password does not appear.
4. Change all.JS back to all.js
5. Attempt to log in to a site that prompts for a password, or a proxy. The 
checkbox appears again and everything else also works fine.

Comment 1

[Daniel Veditz [:dveditz] back January 5, 2026]

Confirming. This is not a password manager problem. If your distribution is not
correctly reading all.js there are all sorts of critical security settings that
will have the wrong defaults.

Is it just prefs that has a problem with uppercase names? Windows is not
supposed to be case-sensitive for filenames.

Comment 2

[Daniel Veditz [:dveditz] back January 5, 2026]

Attachment: case-insensitive extension compare

This fixes the pref issue in this spot, but the whole codebase seems to assume
extensions are in lower-case and similar problems will appear elsewhere.

This makes all platforms case-insensitive, not just Mac, Win and os/2. In this
case that shouldn't be a problem. Picking reviewers based on cvs blame for this
file.

Comment 3

[Daniel Veditz [:dveditz] back January 5, 2026]

Georg: this is unlikely to ever land on the 1.7 branch. You'll have to patch
your own embedding build if you're branch-based.

Comment 4

[Georg Ragaz]

(In reply to comment #1)
> Confirming. This is not a password manager problem. If your distribution is 
not
> correctly reading all.js there are all sorts of critical security settings 
that
> will have the wrong defaults.
> Is it just prefs that has a problem with uppercase names? Windows is not
> supposed to be case-sensitive for filenames.

I have capitalized the whole tree and went on to lowercasing it again and 
ended up at all.js as the only one causing me problems. So it appears that 
just all.js is causing the problem, however I am not able to investigate if 
other files in prefs also cause problems. The most obvious one was the fact 
that the checkbox for password saving did not appear and then I was not able 
to logon to a php site.

Comment 5

[Georg Ragaz]

(In reply to comment #3)
> Georg: this is unlikely to ever land on the 1.7 branch. You'll have to patch
> your own embedding build if you're branch-based.

Does this mean only future versions will have this patched? I have no 
possibility for binary builds, especially not in windows. When can I expect a 
binary version that has the patch included.

Comment 6

[Daniel Veditz [:dveditz] back January 5, 2026]

You're building an embedded device but cannot build from source?

We just released Mozilla 1.7.6 and don't have any current plans for another
release off that branch. I'm sure we will eventually, but when we do it'll be
triggered by the discovery of a new security hole and the build is unlikely to
contain extra fixes (such as this) to reduce the required testing.

When this is reviewed I'll check into the trunk, but a stable release from the
trunk is a ways off. You'll need to either build it yourself, work around the
bug by lowercasing your CD, or hire someone to do a build for you. I'm sure the
latter would be fairly cheap for just this one patch, lots of Mozilla supporters
build regularly.

Try the IRC channels linked from http://www.mozilla.org/support/#community and
ask around for the reputation of whoever responds (ask the bots who people are,
if the bots don't know they likely aren't a regular).

Comment 7

[Darin Fisher]

Comment on attachment 178538 [details] [diff] [review]
case-insensitive extension compare

>+    if (StringEndsWith(leafName, NS_LITERAL_CSTRING(".js"),
>+                       nsCaseInsensitiveCStringComparator())) {

FWIW, you could also write:

  StringTail(leafName, 3).LowerCaseEqualsLiteral(".js")

sr=darin either way

Comment 8

[Daniel Veditz [:dveditz] back January 5, 2026]

Comment on attachment 178538 [details] [diff] [review]
case-insensitive extension compare

bz asked if we could get this one in to 1.7.7

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 178538 [details] [diff] [review]
case-insensitive extension compare

a=asa

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 178538 [details] [diff] [review]
case-insensitive extension compare

1.7.7 has shipped. unsetting request.

Comment 11

[Asa Dotzler [:asa]]

Has this landed?

Comment 12

[Daniel Veditz [:dveditz] back January 5, 2026]

Checked in.