Mozilla 1.1 crashes if I try to access the preferences menu or mail/news manu




16 years ago
10 years ago


(Reporter: pisz, Assigned: bugs)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

I am using Mozilla 1.1 in Mandrake 9.0.  Mozilla worked great for a while,
preferences, mail and news menu.  One day that changed, if I tried to enter the
preferences menu, all of mozilla 1.1 windows disappear.  If I try to access the
mail/news menu, the same thing happens, Mozilla crahes/closes.  My font size
preferences seem to be changed back to default.  My modern theme stayed the
same.  I have no access to preferences manu or the mail and newsgroups manu. 
Composer window does still work.  The broweser still seems to work.

Reproducible: Always

Steps to Reproduce:
1.Open Mozilla
2.Click on the preferences button in the edit menu or the mail & newsgourps button

Actual Results:  
All mozilla 1.1 windows close

Expected Results:  
Open the preferences window or the mail & newsgroups window.

The problem is very annoying as I lost my preferences and the fonts appear to
small, I have lost the ability to set preferences and access the mail and
Newsgourps.  The problem happened one day, Mozilla was wonderfull before this
happened, mail, newsgourps and preferences worked fine.
What happens if you rename your XUL.mfasl file (say to XUL.mfasl.buggy)?  Does
that help?  If so, please zip up the file and attach it to this bug using

Comment 2

16 years ago
Created attachment 110796 [details]
XUL.mfast file just renamed by adding .buggy

Renaming this file by adding .buggy to it restored mozilla and all preferences.
 Renaming this file seemed to solve the problem.
mmm... fastload bugs...
Component: Preferences → XP Toolkit/Widgets: XUL
QA Contact: sairuh → jrgm

Comment 4

16 years ago
Thanks for attaching that file. However, I don't see anything obviously 
wrong with the format, although maybe I need to dig deeper to find what
is wrong.

Since you're crashing, do you get a talkback report generated? [try moving
XUL.mfasl.buggy back in place to trigger the crash again]. Or is talkback
not installed with this build?
Blocks: 134576
Ever confirmed: true

Comment 5

16 years ago
I, too, encountered this bug today after adding email accounts to Mozilla 1.2.1
 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021230) running
under Gentoo 1.4_rc1 and KDE 3.1_rc5. The Window did not close, but simply
"froze" when I selected "preferences" from the "Edit" menu.  Ctrl+Alt+Esc was
able to kill the Mozilla Windows, but mozila.bin processes had to be killed via
KDE System Guard. Renaming XUL.mfast to XUL.mfast.buggy also corrected the
problem for me.  Let me know if you also want my old XUL.mfast file as I have
saved it and will be happy to provide it if needed.
No longer blocks: 134576

Comment 6

16 years ago
Yes, if you could (g)zip up the fastload file and either attach it here, or 
email it to <> that would be much appreciated.

By the way, comment #5 [the hang] is essentially a duplicate of bug 169777 
(and friends), although I had left this one open and separate because (a) I 
was wondering if I could get a crash stack for this example (usually it's a 
hang, not a crash), and (b) this is happening with 1.1 and I was wondering
if there are differences between what is happening in an older release [many
(but not all) of the other reports of fastload problems are with 1.2x and up].
Blocks: 134576

Comment 7

16 years ago
I just experienced the same problem with:

Mozilla 1.2.1 for RedHat 8 - vanilla version
 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
 (it doesn't seem to include talkback)
Installed modules:

I had subscribed to a number of newsgroups on 2 servers. All worked fine, but
the next time I started the system, it behaved as described by the others:
freeze on calling preferences or the mail-news windows.
Renaming XUL.mfast worked (thanks!). 

Should I send my XUL.mfast.buggy too?

Comment 8

16 years ago
No, thanks. I don't need to see a fastload file for 1.2.1 builds. I am 
interested if people can reproduce this in builds after Jan 17th, in which
case I would like to see the fastload file.

*** This bug has been marked as a duplicate of 169777 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Removing 'Blocks: bug 134576', to clear things up there.)
No longer blocks: 134576


10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.