149422 - Editing prefs.js or user.js causes profile init errors

Status: VERIFIED FIXED

(Core :: Preferences: Backend, defect)

Description

[Keith E. Moe]

I'm trying to add the definitions for an external mail program (pmmail) as
posted on the mozilla os2 news group.

Editing prefs.js (ALL editing ALWAYS done with Mozilla shut down) to add the
lines results in an initialization window that says:
 
An error occurred reading the startup configuration file.  Please contact you
administrator.

line 343: SyntaxError: illegal character. %s* (where the * is a right pointing
arrow).

If I restore prefs.js from a backup, everything is fine.  If instead of touching
prefs.js, I instead create a user.js file (which I suppose is the preferred
method), I get the same error, only on line 9.  (I suppose this is better.  I
can count9 lines in user.js, even if it is two lines past the end of file. 
Counting 343 lines in prefs.js would take a LONG time.)

In neither case can I find any type of obvious error.  In many cases, the line
number is beyond the end of the file.

I am using the e.exe editor.

I am using 1.0 GA, but I've had similar errors on earlier releases.

I even edited the prefs.js file and simply deleted and added back the blank line
(nl char?) at the VERY BEGINNING of the file, saved the file with NO OTHER
CHANGES and got the illegal character at the end of the file.  

Here's my complaints about this problem:
 
1.  The line number isn't very helpful when there is no standard way (in OS/2 at
least) to line number the file.  Beyond a couple dozen lines, it's impractical
to count by hand.

2.  The illegal line should be displayed.

3.  The error doesn't say WHICH configuration file contained the error.  There
can be more than one, i.e., prefs.js and user.js.

4. %S* (right arrow) is meaningless as the description fo the illegal character.
 Ther is no %s or right arrow in the file.

5.  When the error box is displayed, the ONLY choice I have is to click OK and
let Mozilla start, then shut it down, then restore the profile file (or
otherwise repair it).  There should be a CANCEL option to terminate Mozilla
immediately.

6.  If the platform's editor (e.exe in this case) is adding some extra
character(s) somewhere in the file (like a ctrl-z or binary zero at the end of
the file), the Profile Manager should NOT get upset about it and produce an
error.  It should just be ignored just as null lines are.

Comment 1

[Conrad Carlen (not reading bugmail)]

-> prefs backend. Can you please attach a copy of the offending prefs file, or
at least the section of it which causes the error to the bug? That would be
easiest way to see what's happening. I can goto or select line numbers or have
line numbers displayed in the margin or see the line number containing the
cursor in the status bar with editors on platforms I use. In other words,
complaint #1 is not so valid.

Comment 2

[Keith E. Moe]

Attachment: zip of two user.js wich cause error

Attached is a user.js and user.js.bad, both of which exhibit the error on the
last line of the file when used in a profile.

Comment 3

[Mike Kaply [:mkaply]]

This will not be easy.

The actual error is coming from Javascript who can't parse files with EOF chars. 
So the bug probably belongs first in Javascript to fix that problem.

As far as the error message goes, the pref code is just passing a function 
called "pref_ErrorReporter" to Javascript, and when the error gets reported, 
javascript doesn't know what file was being parsed - it was just passed a 
buffer.

And there doesn't seem to be any easy way to get the filename to the error 
reporter since it is called directly from Javascript.

I guess the pref code could theoretically remove the EOF before passing to JS, 
but that seems like overkill...

Comment 4

[Mike Kaply [:mkaply]]

Copying brendan for his opinion.

Brendan, should Javascript be able to handle the EOF character in scripts?

Comment 5

[Brendan Eich [:brendan]]

There is no "EOF character" in ECMA-262, and there is no JS bug here: \u001A is
an illegal character in JavaScript source text.

/be

Comment 6

[Keith E. Moe]

So if the EOF character is considered illegal in Javascript, how does one go
about creating or maintains Javascript files or (in this case) Mozilla Profile
files without the EOF character being added?  The OS/2 Editor must add it
automatically, and everyone else that deals with the file, including ASCII FTP
seems to have no problem with it.

Comment 7

[Mike Kaply [:mkaply]]

The answer is that the OS/2 E.EXE editor is HORRIBLY broke.

Noone adds an EOF character except for our editor. As in noone on the 
entire planet. We suck. Even DOS editors don't add EOF.

I'm going to put an OS/2 hack in preferences that takes the EOF away 
before parsing.

And I am going to put something in the README not to edit files with 
E.EXE.

And I am going to open an OS/2 bug to get E.EXE fixed.

Comment 8

[Mike Kaply [:mkaply]]

Attachment: OS/2 only hack

Comment 9

[Felix Miata]

I began a thread in news:comp.os.os2.bugs 22 Aug 2000 entitled "E.EXE Remains
Broken in FP14". During the thread I posted the following:

Appends
  1Ah	Editor/Application
Yes
IBM PC DOS 6.1 EDLIN.COM (probably since DOS 1.0)
Yes
IBM PC DOS 2000 E.EXE
Yes
IBM OS/2 E.EXE (system default)
No
IBM OS/2 EPM.EXE
No
IBM OS/2 TEDIT.EXE
No
Norton Commander (internal editor)
No
M$ DOS 6.22 EDIT.COM
No
Freeware TED.COM
No
WordPerfect 6.2 for DOS
No
Composer 4.61 for OS/2
No
File Commander/2 for OS/2 (internal editor)

Scott Garfinkle replied unofficially on behalf of IBM: "WAD".

Besides the news thread I started, I also submitted to IBM a "free" bug report
on the designated form. IBM offically replied via email on 25 Aug 2000: "WAD".

Maybe you will have better luck with IBM than I did and rather than opening a
new bug you could get mine revisited or appended: "17882,psc".

Since then, an OS/2 freeware author has been releasing a patched version of
E.EXE, which ultimately Serenity Systems started making available for download
on their web site for eCS users. The only problem with this solution is it must
be reapplied after each fixpak application, since each replaces E.EXE with a 1A
WAD version. You might want to note this in the readme, as well as that EPM and
TEDIT are not similarly broken.

Comment 10

[Felix Miata]

1-geez, why did Bugzilla convert all my tabs to spaces? Those yes's and no's
were supposed to have the apps follow on the same lines.

2-Mike Kaply, you seem to have confirmed this without marking it so, and my
E.EXE does not append 1Ah to text files.

Comment 11

[Brian Nesse (gone)]

Comment on attachment 87986 [details] [diff] [review]
OS/2 only hack

>     if (readBuf[fileSize-1] == 0x1A) {
It's probably safer to check against amtRead... just in case it was different
then fileSize. Also, please add some white space around the "-". With those
changes r=bnesse.

Comment 12

[Mike Kaply [:mkaply]]

Attachment: patch with bnesse's comments

I also cleaned up the comment a bit :)

Comment 13

[Brian Nesse (gone)]

Comment on attachment 88340 [details] [diff] [review]
patch with bnesse's comments

r=bnesse.

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 88340 [details] [diff] [review]
patch with bnesse's comments

sr=jst

Comment 15

[Mike Kaply [:mkaply]]

Fix on trunk. Might try branch.

Comment 16

[Brian Nesse (gone)]

Marking fixed to induce trunk verification.

Comment 17

[Felix Miata]

Somebody needs to put up a trunk build with the fix in. No OS/2 builds put on
the Mozilla FTP server since this fix went in.

Comment 18

[Mike Kaply [:mkaply]]

Build is now up at latest

Comment 19

[Rodney Velasco]

reassigning to [e-mail] per sairuh's suggestion, adding keywords to
get some QA help for verification.

Comment 20

[Mike Kaply [:mkaply]]

Reporter, could you verify?

This works on a current trunk build.

Comment 21

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 22

[Mike Kaply [:mkaply]]

fix on branch

Comment 23

[Mike Kaply [:mkaply]]

I have verified that this is fixed.