SMAPI preference setting fails to be saved from Mail/Newsgroup window.

VERIFIED FIXED in mozilla1.0.1

Status

MailNews Core
Simple MAPI
P2
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Trix Supremo, Assigned: Srilatha Moturi)

Tracking

Trunk
mozilla1.0.1
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2 rtm])

Attachments

(1 attachment)

3.64 KB, patch
Srilatha Moturi
: review+
Scott MacGregor
: superreview+
Judson Valeski
: approval+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
The SMAPI preference setting cannot be changed from the Mail/Newsgroup window.
This setting can be changed from the Browser, but not from the Mail/Newsgroup
window.

STEPS:
1. Launch browser, goto preference panel enable, and save preference for SMAPI
to be the default email client.
2. Go back to pref panel to verify the setting was saved.
3. Open Mail/Newsgroups window and attempt to disable SMAPI from the pref panel
and save the changes.
4. Now go back to the pref panel to verify if the setting has been changed.

RESULT:
The prior setting remains, SMAPI was not disabled. The registry also validates
that Netscape 6 is still the default email client.
(Reporter)

Comment 1

17 years ago
nominating for nsbeta1
Keywords: nsbeta1

Updated

17 years ago
Priority: -- → P2

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0

Comment 2

17 years ago
Discussed in Mail News bug meeting.  Decided to ADT2 this bug.
Whiteboard: [ADT2]
(Assignee)

Comment 3

17 years ago
Based on conv. with rajiv taking this.
Assignee: rdayal → srilatha

Comment 4

17 years ago
This is a duplicate of what was earlier seen as reported and fixed in bug #
103260. A similiar fix can be applied here with some changes to comply with the
changes done for trunk landing in the pref-mailnewsOverlay.js code. 
(Assignee)

Comment 5

17 years ago
Created attachment 78967 [details] [diff] [review]
patch v1

When the preferences is opened from Browser or any other component other than
Mail/News before we call mailnewsOverlayStartup() the Startup() method(which
initalizes hPrefWindow) in pref.xul is getting called. But when we open
preferences from Mail/News mailnewsOverlayStartup() is getting called before
Startup().
http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/content/pref.xul#32


We fixed a similar problem on 0.9.4 branch by doing the callback registration
from Startup in pref-mailnews.js. bug # 103260.
I change the Init() function in pref-mailnews.js since it is not needed anymore
because of the eventlistener code in pref-mailnwsOverlay.js

Comment 6

16 years ago
We looked into alternatives such that we can fix the problem locally in 
pref_mailnewsOverlay.* using an event listener but that is not possible in this 
case since load event does not work as per above comments and no other events 
could be used to get notified onOk.

Srilatha, can we not minimize the changes in pref-mailnews.* by naming 
the 'registerCallback' function in pref-mailnewsOverlay.xul as 'initFunc' 
instead of 'startupFunc' ? Will it lead to same problem ? 

Also please make sure Startup will always be called after hPrefWindow has been 
initialized if you find that changing pref-mailnews.* is necessary and by just 
naming registerCallback() as initFunc will not work.
(Assignee)

Comment 7

16 years ago
> Srilatha, can we not minimize the changes in pref-mailnews.* by naming 
> the 'registerCallback' function in pref-mailnewsOverlay.xul as 'initFunc' 
> instead of 'startupFunc' ? Will it lead to same problem ?
Naming the registerCallback function initFunc or startupFunc doesn't make any 
difference. But I named it startupFunc because this is getting called from 
Startup().

Startup() gets called only after hPrefWindow is initialized. 
Startup gets called from nsPrefWindow.onPageLoad
http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒0﷓
nsPrefWindow.onPageLoad gets called from two places
1) from nsPrefWindow.Init()which gets called only if hPrefWindow is not null
http://lxR.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒1http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒2﷓

2)from InitPanel() only if hPrefWindow is not null
http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒3

Comment 8

16 years ago
>> Naming the registerCallback function initFunc or startupFunc doesn't make  
>> any difference. But I named it startupFunc because this is getting called  
>> from Startup().

Naming the registerCallback function initFunc instead of startupFunc Will make 
a difference, if you do that you will not have to change the pref-mailnews.js 
and pref-mailnews.xul at all, Only your pref-mailnewsOverlay.* changes could 
suffice.

Anyway as per your comments about Startup function in comment #7 not changing 
pref-mailnews.* will lead to same problem. So your changes are fine.

r=rdayal.

(Assignee)

Updated

16 years ago
Attachment #78967 - Flags: review+

Comment 9

16 years ago
I'm slightly confused. Who ends up calling function Startup()? I couldn't see a
caller in the patch. 
(Assignee)

Comment 10

16 years ago
This is where Startup() gets called. From nsPrefWindow.onPageLoad().
http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/content/nsPrefWindow.js#369
Status: NEW → ASSIGNED

Comment 11

16 years ago
Comment on attachment 78967 [details] [diff] [review]
patch v1

ahh! thanks!

sr=mscott
Attachment #78967 - Flags: superreview+
(Assignee)

Comment 12

16 years ago
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

16 years ago
Trix, could you try this out on the trunk.
Keywords: adt1.0.0
Whiteboard: [ADT2] → [ADT2 rtm]
(Reporter)

Comment 14

16 years ago
verified on trunk builds 2002052008
Status: RESOLVED → VERIFIED

Comment 15

16 years ago
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Drivers approval.
Blocks: 143047
Keywords: adt1.0.0 → adt1.0.1+
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 16

16 years ago
please checkin to the 1.0.1 branch ASAP. once there please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.
Keywords: mozilla1.0.1+

Updated

16 years ago
Attachment #78967 - Flags: approval+
(Assignee)

Comment 17

16 years ago
Fix checked into the branch
Keywords: adt1.0.1+, mozilla1.0.1+ → fixed1.0.1
(Reporter)

Comment 18

16 years ago
verified on branch build 2002061108 changing keyword fixed1.0.1 to verified1.0.1
Keywords: fixed1.0.1 → verified1.0.1
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.