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.
nominating for nsbeta1
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0
Discussed in Mail News bug meeting. Decided to ADT2 this bug.
Based on conv. with rajiv taking this.
Assignee: rdayal → srilatha
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.
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
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.
> 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/con0 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/con1 http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con2 2)from InitPanel() only if hPrefWindow is not null http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con3
>> 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.
I'm slightly confused. Who ends up calling function Startup()? I couldn't see a caller in the patch.
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 on attachment 78967 [details] [diff] [review] patch v1 ahh! thanks! sr=mscott
Attachment #78967 - Flags: superreview+
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Trix, could you try this out on the trunk.
Whiteboard: [ADT2] → [ADT2 rtm]
verified on trunk builds 2002052008
Status: RESOLVED → VERIFIED
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending Drivers approval.
Keywords: adt1.0.0 → adt1.0.1+
Target Milestone: mozilla1.0 → mozilla1.0.1
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.
Fix checked into the branch
Keywords: adt1.0.1+, mozilla1.0.1+ → fixed1.0.1
verified on branch build 2002061108 changing keyword fixed1.0.1 to verified1.0.1
Keywords: fixed1.0.1 → verified1.0.1
You need to log in before you can comment on or make changes to this bug.