Preferences are not read on Mozilla Mac

VERIFIED DUPLICATE of bug 5132

Status

()

Core
JavaScript Engine
P1
major
VERIFIED DUPLICATE of bug 5132
19 years ago
16 years ago

People

(Reporter: Peter Van der Beken, Assigned: Mike McCabe)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Problem resolved on Mail. Leaving bug for Paulmac to verify)

(Reporter)

Description

19 years ago
Steps to reproduce:
Using a Mac build:

1) enter proxy preferences in the user50.js preference file
2) launch the browser
3) you can't access non-local pages, because the proxy information is not loaded
4) could be tested with other prefs (i found out with proxy settings)

The preferences are not being read on the Mac version of Mozilla. Aparently,
things go wrong in the function pref_InitInitialObjects() in
module:libpref:src:mac:macpref.cp at line 114. The statement "JSBool ok =
pref_ReadResource(3000);" always returns False in "ok", thus none of the other
ReadResources lines get called and the user preference file also doesn't get
read in.
I tried following execution from prefReadResource, and i think the resource gets
read in ok but the Javascript evaluation fails. That part is so complicated
though that i stopped looking when Javascript kicks in. So i'm not completely
sure this is a libPref or a JavaScript bug.

This was checked to be reproducible on MacOS 8.5.1 with the 5-5-1999 build, and
was seen in earlier builds too.

Haven't tested on other platforms.

Updated

19 years ago
Priority: P3 → P2
Target Milestone: M6

Comment 1

19 years ago
John ...

Updated

19 years ago
Target Milestone: M6 → M7

Updated

19 years ago
Target Milestone: M7 → M6

Comment 2

19 years ago
This actually looks fairly serious. Moving back to M6

Comment 3

19 years ago
According to John, Mail is also broken because mail depends on reading the
pref50.js file.

Updated

19 years ago
Priority: P2 → P1
Summary: Preferences are not read on Mozilla Mac → Stopper - Preferences are not read on Mozilla Mac

Updated

19 years ago
Severity: major → blocker

Updated

19 years ago
Severity: blocker → major
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 4

19 years ago
Fixed. This fix will appear in today's final Macintosh build.

Updated

19 years ago
Whiteboard: Problem resolved on Mail. Leaving bug for Paulmac to verify

Comment 5

19 years ago
Using the May 5 1999-05-05-15 build, the preference file is now being read on
the Mac.  Mail folders and messages now appears again.
  This bug is verified on Mail.
Leaving this bug for Paulmac to verify on the browser issue.

Great work John! :)

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 6

19 years ago
Verified - you can set prefs via the UI and they show up just swell the next
time you run.
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
Component: libPref → JavaScript Debugger
(Reporter)

Comment 7

19 years ago
I have found what the problem with prefReadResource() is: in two of the

javascript configuration files ("modules:libpref:src:initpref.js" and

"modules:libpref:src:init:all.js") there are blank lines at the end of the file,

after the last javascript statement. Removing these lines allows the

pref_ReadResource function to succeed. So the fix is simple: make it so that

those javascript files have only one newline after the last statement.



IMHO the extra lines are something that the javascript parser should be able to

deal with, so with the approval of John McMullen, i'm reopening this bug

assigned to JavaScript.

The bug is that on the Mac build, the JavaScript parser fails if there are blank

lines at the end of a .js file.

I haven't tested this on other platforms, but i tried changing the line endings

to Unix \n (instead of Mac \r) and the extra lines didn't choke the parser then.

It's got to do with detecting new lines but only mac-style new lines.
(Reporter)

Updated

19 years ago
Assignee: mcmullen → mccabe
Status: REOPENED → NEW
(Reporter)

Updated

19 years ago
Resolution: FIXED → ---
(Reporter)

Updated

19 years ago
Component: JavaScript Debugger → JavaScript

Updated

19 years ago
Summary: Stopper - Preferences are not read on Mozilla Mac → Preferences are not read on Mozilla Mac

Comment 8

19 years ago
Removing the word "stopper" from the summary.
(Reporter)

Comment 9

19 years ago
The bug is in jsscan.c in the function GetChar. When this function reads the
last character which on Mac is a CR in these preference files, it returns a CR
then a LF and then it starts returning characters which are not from the file
(where do they come from?). It should return a CR, a LF and then an EOF. If you
change the line endings in the JS files to UNIX the last character is a LF, it
returns a LF and then an EOF, which is correct.
This bug causes a variety of other Javascript compilation errors in perfectly
valid JS files. This can be seen when the files referenced from the XUL files
(eg navigator.js, referenced from navigator.xul) are read during initialisation.

Comment 10

19 years ago
Adding myself as cc:
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

19 years ago
First of all, thanks for the great exchange on this bug report.  I just stood
back and watched the facts come in... :)

I've been able to reproduce this xp.  In the standalone javascript engine (gmake
-f Makefile.ref in /mozilla/js/src) executing

eval("print('hello, world')\r\r");

... results in an error.

sil.js:4: illegal character:
rint('hello, world')

sil.js:4: ......................^

(Change 'print' to 'alert' if you're in the browser.)  Depending on the eval
string, I might also get other errors, like 'unterminated string'.  It looks
like the engine is indeed getting garbage characters.  The error goes away when
those \rs are changed to \ns, or with just one \r.

Setting the status to assigned.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

19 years ago
Checked in a fix.

(aargh, forgot to credit the excellent sleuthing in the log.  Sorry!)

Turns out that this problem appeared when we removed the JSFILE (read js source
from a filehandle) #ifdef.  In the from-a-file case (only) we read the file into
a circular buffer.  js handles \r \n \r\n by collapsing to \n in the buffer, but
it has to special-case \r ending a buffer.  The code ran into trouble when \r\r
ended the buffer; it tried to advance the reading pointer past the end marker,
and then (because of an ==, not >, check) it merrily read on from there.

Fixed in two ways:

- This check now doesn't fire at all unless we're reading from a file.  This
means that all mozilla code prior to the removal of the JSFILE #ifdef is OK.
(jband?)  I'm sure this fixes the non-file case.

- Added a recursive GetChar() call to escape out of the \r buffer-ending check
and start over whenever we're in the accidental-overflow case.  I'm mostly sure
this fixes the file case.

Comment 13

19 years ago
Pter, can you verify the fix? Thanks. Prefs still look good, but you were seeing
some initialization problems.
(Reporter)

Comment 14

19 years ago
Prefs are read in, JS bug is gone. I think this bug is resolved. Last thing to
do: remove John's workaround in macpref.cp (line 109 to 111 and line 135).

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 15

19 years ago
Yes, and I have some changes in my tree. However, the remaining bug is really
subsumed under bug #5132. So I'm now marking this as a duplicate, in order to
make use of Bugzilla's nifty cross-linking feature.

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: FIXED → DUPLICATE

Comment 16

19 years ago
Reopened, then marked as a duplicate.


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

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 17

19 years ago
Yep...a dup...Verified

Comment 18

19 years ago
Changing component to "Javascript Engine".  "Javascript" component is being
retired.
You need to log in before you can comment on or make changes to this bug.