Noticed this on 2001050904 windows nt 4.0 and 2001050808 on Mac If you click on Offline&Disk Space pref for a News account, then click on a Offline&Disk Space pref for a Mail account, you will still see the bottom half of the News account version of Offline&Disk Space pref. steps to reproduce. 1) Click on Offline&Disk Space pref for a News account 2) Now click on an Offline&Disk Space pref for a Mail account Actual results: you see the bottom half of the Offline&Disk Space pref for News ("When it's time to clean up messages") while you are still on Offline&Disk Space pref for Mail. Sometimes it will dissapear after a few seconds. Expected results: Not to see it at all. That part of the gui should be empty. Not sure this is really a problem with offline, Diane. Seems like a rendering problem? Please reassign if this is true.

This was showing before and it turned out not my problem. Previous couple of days build did not have this problem. Not sure what causes this regression.

ok should I mark invalid or reassign?

If you know whom to reassing, please go ahead to do so.

hmm not sure either. ccing scott and david.

Note I also see it when I toggle between a imap, pop, and newsgroup accounts. I guess because each gui window for Offline&Disk Space is a different size in imap, pop, and newsgroup accounts. Pop being the smallest and Newsgroup being the largest. So when you switch back and forth, it tries to redraw but doesn't clean up the previous window. If you move the Account Settings window off the screen, it will 'erase' the gui that isn't supposed to be showing.

With changes I checked in (for bug 76388)..looks like this problem is gone. Anyway, please verify with tomorrow's build. bhuvan

Using the 2001052020 build on NT 4.0 and 2001052115 linux 2.2 and 2001052112 on MAC OS 9.04 It looks better but the GUI still isn't display correctly. On Windows and MAC the basic problem is gone. I don't see remnants of the previous windows when toggling between a pop, imap, and news offline & disk space prefs. Though for News offline & Disk Space pref, the GUI is still getting a tiny bit 'cut off' as it appears the gui is larger than the 'default size' of the gui window. So you have to resize the window to display it properly. For Linux, I am still seeing the problem. It looks fine if you toggle between pop and imap offline & disk space settings. When you click on News's offline and Disk Space prefs, it appears it is slightly getting 'cut off' like I described for Windows and MAC. But if you toggle: starting with News Offline & Disk Space pref, then click on a IMAP Offline & Disk Space pref, you will see the problem still exists. The IMAP Offline & Disk Space pref is pasted over News Offline & Disk Space pref and you can still see parts of News pref gui. Only happens with Linux builds as I don't see this on Windows or Mac. Leaving bug as new. Not sure whether I should create a new bug for 'cut off' gui and maybe one specific to Linux only.

The problem is caused by no default property setting for radio group selectedItem. Bug 80194 fixes nntp radio buttion default setting. But in IMAP, the default setting will not be set because the initial download setting was commented out for IMAP. No matter these radio buttons are hidden for IMAP, the property should still be set.

note to diane, I can't sr= until this is reviewed.

Diane, How is that setting defaults for NNTP items linked to proper repaint ? If you open those 2 routines (initRetentionSettings(); & initDownloadSettings();) for IMAP and POP, isn't that invalid trying to access all those nntp.* elements in IMAP and POP panels ? Please explain the solution further for my better understanding. As such in the current state, I don't seethis problem on Windows. Looks it's OK on mac also. When a panel patch is agrred upon, please do test your patch on all 3 platforms to make sure no side-effects are introduced. bhuvan

For the radio group, it needs default property initialized even that group is hidden for imap and pop and only shown for nntp. Previously we had the initialization only for nntp. The problem is currently only happening on Linux not on Windows and Mac.

I suppose that even though the values for the prefs being loaded in the init functions aren't valid, they'll never be saved since those elements should never change state. I applied the change and played around with it a bit, but didn't see anything obviously horked in the prefs file after saving. r=eddyk

Using commercial builds 2001-06-20-09-trunk/ -win nt 4.0 2001-06-20-08-trunk/ -linux 2.2, red hat 7.0 2001-06-20-08-trunk/ mac 9.0.4 Note: I am seeing a regression when displaying Offline & Disk Space prefs with today's builds. POP accounts Disk Space prefs gets changed to IMAP Offline & Disk Space pref when you click from POP->IMAP->POP This occurs on all platforms. Steps to reproduce: 1.Create a brand new profile 2.Start Messenger 3.Create 2 mail accounts a. IMAP mail account b. POP mail account 4.After done creating both accounts click ok to close Account Settings window. 5.Go back to Edit|Mail/News Account settings 6.Click on POP Mail account first 7.Click on Disk Space Under the POP mail account 8.Notice it displays Title: Disk Space One pref shows: Do not download messages locally larger than x kb 9.Click on IMAP account 10.Click on the Offline & Disk Space pref 11.Notice it displays: Title: Offline & Disk Space 3 prefs for offline: Make mesgs in inbox downloadable,create new folders for offline use, and Disk space pref. 12.Click back on Pop account 13.Click Disk Space under Pop account 14.It now has prefs that were found in IMAP. 15.Clicking another pref (say addressing) and going back to disk space results in no change other than Title being changed from "Offline and Disk space" to "Disk Space" 16.Loging out/restarting messenger does not refresh it. In fact it makes it worse, as Under PoP accounts it now lists Offline & Disk Space instead of Disk Space I don't see this problem toggling between newsgroups or webmail accounts. It's Like POP accounts inherit any imap accounts prefs. This happens on all Platforms. Not sure it is tied in with the whacky problems we are seeing with Mail (bug 86683)?

I think I know what gchan is seeing what he is seeing. there is a js error in the am-offline.js Here's the fix: - isDownloadLocked = pref.PrefIsLocked("offline_download"); + isDownloadLocked = pref.prefIsLocked("offline_download"); if(isDownloadLocked) document.getElementById("offline.newFolder").disabled = true; - isGetNewLocked = pref.PrefIsLocked("download_bodies_on_get_new_mail"); + isGetNewLocked = pref.prefIsLocked("download_bodies_on_get_new_mail"); if there is a bug where pref locking isn't working on the "offline pane", that would be the cause. I'll drive my fix in and fix both problems.

the title problem is now bug #86996

Adding keyword regression based on bug 82805

Commercial Builds 2001-06-21-09-trunk win nt 4.0 2001-06-21-08-trunk/ mac 9.0.4 2001-06-22-11-trunk/ linux 2.2, red hat 7.0 That problem that i was seeing (6/20) with pop and imap accounts is now gone.

Request SR, Seth?

Request SR again?

Missed 0.9.3.

sorry for the delay. sr=sspitzer

checked in.

Commercial builds 2001082203 - win nt 4.0 2001082208 - linux 2.2, mac 9.0.4 Diane, I'm seeing a problem with Linux builds. Toggling between IMAP's 'Offline & News' and News's 'Offline & News' results in them overlapping each other. I notice when I toggle between the two, In my terminal window I see this message 'Warning prev sibling is not in our list' Happens in both themes. No problems with the windows/mac builds. Tested both themes. Exactly like my comments on 2001-05-21 18:01. Should I close this bug and reopen a Linux only bug? Reopening bug for now...

Maybe Eddy could take over this.

Greg - Should this be marked with nsenterpise+?

changing milestone

Using 20010919 commercial branch builds on win nt, linxu 2.2, and mac 9.1, I do not see this refresh problem anymore. Even the problem with the linux builds (see comments on 2001-08-22 19:35) that I was seeing is no longer there. Going to mark as works for me now. But will reopen this bug if the problem creeps up again.