If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Can not set to default mapi client checkbox in preferences is missing with error text in its place

RESOLVED DUPLICATE of bug 253240

Status

MailNews Core
Simple MAPI
--
major
RESOLVED DUPLICATE of bug 253240
13 years ago
6 years ago

People

(Reporter: Tony Chandler, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040728
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040728

Using latest nightly build, the checkbox in preferences to set mozilla as the
default mail client is no longer there and is replaced by larger red text as follows

<checkbox id="mailnewsEnableMapi" labe
^

The above appears to be truncated by the preferences window.

Tried with a clean profile and install makes no difference.

Reproducible: Always
Steps to Reproduce:
1.Edit > Preferences
2.>Mail & Newsgroups
3.

Actual Results:  
Prefence check box for setting Mozilla as default mail client MIA, but replace
by error text.

Expected Results:  
Check box to select mozilla as default mapi client

Comment 1

13 years ago
Confirming with Mozilla 2004072708 on Win NT 4.0.

Additionally I would not asked if I want to set Mozilla as the default mailer on
first start of Mailnews.

Please add the keyword regression.

Comment 2

13 years ago
Regression timeframe between 2004072307 and 2004072708 (from dupes) but I
haven't tested it to narrow it down.

Comment 3

13 years ago
*** Bug 253689 has been marked as a duplicate of this bug. ***

Comment 4

13 years ago
attachment 154757 [details]
screenshot 2004072909-trunk/WinXP

Comment 5

13 years ago
First test regression between 2004072307 and 2004072408
but with that build no script error, but missing checkbox

Comment 6

13 years ago
(In reply to comment #5)
> First test regression between 2004072307 and 2004072408

That was wrong. I tested with all available builds for me on WinNT4 again.
build 2004072408 works, 2004072509 fails

checkins during that timeframe
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=07%2F24%2F2004+08%3A00&maxdate=07%2F25%2F2004+09%3A00&cvsroot=%2Fcvsroot

I guess Bug 252056 is guilty in particular the changes to jar.mn and so on.
http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fmailnews&file=jar.mn&rev1=1.77&rev2=1.78&whitespace_mode=show&diff_mode=full
It seems the move from en-win.jar to en-US.jar is not reflected in
chrome.rdf/installed-chrome.txt etc. See also duplicate bug 253642 comment 2.

Comment 7

13 years ago
*** Bug 253642 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
This is a regression ...

Mozilla 2004080408 on WinNT4. There seems now only one wrong file in the config
due to Bug 252056. I have found a workaround for it. You have to edit the file
installed-chrome.txt in your [Mozilla_Program_Path]\Mozilla\chrome directory.

Exit Mozilla completely and change the line

locale,install,url,jar:resource:/chrome/en-win.jar!/locale/en-US/messenger-mapi/

to

locale,install,url,jar:resource:/chrome/en-US.jar!/locale/en-US/messenger-mapi/

and move the line to the other en-US lines. Now start Mozilla two times. Now it
should work because the chrome.rdf is updated.

Comment 9

13 years ago
still not fixed ... 2004080509

2 symptoms: first the one from comment 0 and the second one from comment 1

Comment 10

13 years ago

*** This bug has been marked as a duplicate of 253240 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 11

13 years ago
(In reply to comment #8)
 
Thanks, Ostgote, for this workaround. I also had to delete XUL.mfl to get it
working.
After starting, first time Mozilla took a very long time on my slow machine
until the Profilemanager came up.
When I saw the bug still after third start, I closed the browser, deleted
XUL.mfl, restarted, and it was gone.
Product: MailNews → Core
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.