Closed Bug 192119 Opened 22 years ago Closed 17 years ago

Can't enable Junk Mail controls unless "whitelist" address book is selected

Categories

(MailNews Core :: Filters, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: rcharbon, Unassigned)

References

Details

(Whiteboard: [see comment 12])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030202
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030202

When you first select "Enable Junk Mail Controls" and click on OK, nothing
happens.  You need to enable "Do not mark messages...", then select an address
book (by default, the address book field is blank) before you can successfully
enable the Junk Mail controls.  
Once you've selected an address book, you can't return to the problem state (you
can't clear the address book field).  Once an address book has been selected,
the state of the "Do not mark messages..." checkbook does not affect the ability
to enable the Junk Mail controls.
This has been a problem since I first tried it, in 1.3a.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
QA Contact: laurel → esther
I am encountering a similar but different problem. The following demonstrates my
problem:

Case 1

1. Select the menu item "Tools/Junk Mail Controls..." to open the Junk Mail
Controls dialog. When opened, all dialog controls are selectable.

2. Select an account.

3. Click the "Enable junk mail controls" checkbox. UNEXPECTED: the "Move
incoming messages determined to be junk mail to:" checkbox becomes unselectable.
Note that the controls subsidiary to it stay active.

4. Click the "Do not mark messages as junk mail if the sender is in my address
book" checkbox.

4.a. You may or may not select an address book from the pulldown menu control.
This does not affect what happens.

5. Click the "Other" radio button. Now, all of the controls under the "Move
incoming messages..." checkbox become unselectable.

6. Press the "OK" button. Nothing happens

Case 2:

1. Perform steps 1-4.a in case 1. 

2. Press the "OK" button. Nothing happens.

I would expect behavior something like the following:

a. The "Account" pulldown and the "Enable junk mail controls" checkbox are
always active. The "Account" pulldown should have a default value that is not
blank, but set to the first account.

b. The "Do not mark...address book:" and "Move incoming messages...mail to:"
checkboxes are active only if the "Enable junk mail controls" checkbox is checked. 

c. The address book pulldown menu is active only if the "Do not mark...address
book:" is checked.

d. The "'Junk Mail' folder on:" radio button, "Other:" radio button, and
"Automatically delete...after [] days" check box are active only if the "Move
incoming messages...mail to:" is checked.

e. The pulldown menues next to the radio buttons are only active if the correct
radio button is selected.

f. The "days" text box should be active only if the "Automatically delete..."
checkbox is checked.

NOTE: unchecking a control should not only deactive the dependent controls, but
set them to be unchecked where appropriate!

The "OK" button also needs to be fixed.
Using commercial trunk build 20030202 and 20030205 on winxp and linux, I can't
reproduce any of these problems except this one: The OK button does nothing if
you select the "Other" radio button but don't change the default from the server
to a folder on the server. I will look for a dup or log separate bug for that. 
Reporters, can you try a new profile to see if the problem is with your profile
or the builds you are taking.   
First, I upgraded Mozilla to:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

Then I created a new profile, and opened the Junk Mail controls. The new profile
had the Personal Address Book already selected as the 'whitelist' address book
(where the field had been blank in previous profiles).  Since there was an
address book selected, I was able to enable the junk controls and select OK.

The problem may have originally occured because I don't have a Personal Address
Book in my other profiles.  I don't have one on the system I'm looking at now,
and I don't _think_ there's one at home.  Both systems had their address book
imported from Netscape 4.79.    
I had a similar problem - the "OK" button didn't do anything until I created a
"Junk" folder on the server
I'm having the same problem except that no matter what I do, as long as the
"Move incoming messages labeled as Junk..." checkbox is checked, the OK button
has no effect.

(BTW I had to manually create the junk folder -- shouldn't it get created
automatically?)  

Since I couldn't get this to work, I decided then to make my own message filter
for moving junk-tagged messages into the Junk folder. Unfortunately this message
filter doesn't have any affect unless I run it manually. I suspect this is
beause messages that are not tagged as Junk until after the new mail filters are
applied.  Perhaps I should report this as a seperate bug?
esther, do you see this?
Assignee: naving → sspitzer
I'm not sure what the problem is now.  The originally reported problem doesn't
happen anymore and with current builds we now create (if there isn't one
already) a Junk folder when the user selects the option to move it to the Junk
folder. We have the JMC ON by default and checking against the Personal Address
book ON by default. Uri and Bert you need to state the build ID your using when
you see your problems, if the build is older than 3-18-2003, please take a newer
build and try your scenario again. If you still have a problem similiar but not
the same steps to the originally stated scenario, please list new steps.  Thanks
Esther, the original bug reported in comment 0 still manifests when the selected
addressbook has been deleted.  Included is the report I was about to file before
finding this bug:

WinXP, 1.4-RC3
Looking at the JMC dialog, for the selection "Do not mark... if sender is in my
address book," when the selected addressbook is deleted the dialog stops
working.  Specifically, the select box for address book becomes smaller than
normal, and changing accounts (at top of dialog) doesn't update the JMC window
to new account's settings.

Steps to Reproduce:
1. Enable junk mail controls for two accounts.  Enable different sub-settings to
make them distinguishable from each other.
2. In first account, select an address book under "Do not mark messages as junk..."
3. Close JMC dialog, and delete that address book from the AddressBook app.
4. Re-open JMC dialog.  Observe the empty addressbook select-box.
5. Try to change to the other mail account.  Notice that no settings are updated
in the JMC dialog.

Actual Results: JMC dialog malfunctions as described.  Selecting an existing
addressbook restores normal functionality.

Expected Results:  Selection should default to another addressbook or remain
empty without killing JMC functionality.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 207712 has been marked as a duplicate of this bug. ***
*** Bug 212935 has been marked as a duplicate of this bug. ***
*** Bug 212744 has been marked as a duplicate of this bug. ***
I had the same/similar problem. After changing some details on my mail account,
junk controls didn't work and the junk controls control panel wouldn't save any
of the changes I made. 

I fixed the problem by making a change to my prefs.js. It looked like
spanActionTargetAccount had become "out of sync" with reality after I'd changed
my mail account details (I would hazzard a guess that spanActionTargetAccount
didn't get updated when I made my mail account changes).

Anyway, it appears that the correct setting is:

spamActionTargetAccount = "mailbox://" + userName + "@" + hostname

with escaping occurring so any slashes in the userName gets turned into %2F. 

This is what I now have which works:

user_pref("mail.server.server1.hostname", "127.0.0.1");
user_pref("mail.server.server1.userName", "colin/theblakes.com");
user_pref("mail.server.server1.spamActionTargetAccount",
"mailbox://colin%2Ftheblakes.com@127.0.0.1");
Colin Blake, what anti-virus software do you use?
If "Norton" family or "Virus Baster" family oe "McAfee" family, see Bug 213300 also.
I have experienced a similar situation using Mozilla 1.5, just released.  Using
Win 98 SE, The OK button has no effect when I try to configure the Junk Mail
Controls.    I have not found a worrk-around (tried several that were mentioned
in various comments under this bug report.
*** Bug 225129 has been marked as a duplicate of this bug. ***
*** Bug 207031 has been marked as a duplicate of this bug. ***
*** Bug 211180 has been marked as a duplicate of this bug. ***
*** Bug 223860 has been marked as a duplicate of this bug. ***
*** Bug 213872 has been marked as a duplicate of this bug. ***
Bug 221415 is Thunderbird bug.
Although hostname in Bug 221415 is "localhost" (by TrendMicro's PC-Cillin, Virus
Baster in Japan) instead of 127.0.0.1 (by Norton or McAfee), same secnario is
applicable.
In addition to damage on Junk Filter, Bug 221415 describes about damage on
Message Filters when hostname/username in prefs.js are changed by other than
Mozilla/Thunderbird such as anti-virus software.
I experienced exactly the same problem as Ray Charbonneau originally reported in
a newly installed copy of 1.5.  To be clear, as Ray implied but did not specify
explicitly if you enable "Do not mark messages..." without selecting an address
book, hitting "OK" still does nothing.  Unselecting "Do not mark messages..."
and hitting OK without having selected an address book still does not allow you
to have an "OK" click accepted.

Perhaps not coincidentally, I work for the same organization as the original
poster, and likely have similar profile settings.  I also imported an address
book from Netscape 4.79.
For reporters experiencing the problem as originally described -- where the JMC 
dialog's setting for the whitelist is blank (this is the dropdown under the 
[]Do Not Mark As Junk... checkbox):

With the program in the problem state, what settings do you find in prefs.js for 
these preferences for 'serverX' (server1, server2, etc...)
  mail.server.serverX.name
  mail.server.serverX.hostname
  mail.server.serverX.spamActionTargetAccount


I tested what happens when the mail program is started with prefs.js containing 
blank or bogus values for   mail.server.serverX.whiteListAbURI   (which is the 
preference controlling the value in that dropdown).  I was able to get the 
program into a state where that dropdown is blank (and the checkbox is cleared) 
and still having Mozilla save changes to the dialog once made.

However, changing the string for the 'spamActionTargetAccount' results in the 
reported symptoms, as described in comment 12.  In fact, by changing that 
preference (and restarting!) I can put the program into a state where the 
dropdown is NOT blank, and the checkbox can have any state, and still the Ok 
button does not work to save the settings -- altho they are properly loaded (as 
can be seen by changing their corresponding settings in prefs.js).

xref bug 221386.

(Note that bug 221415 is in fact not related to this bug.)
Whiteboard: [see comment 12]
Following up on my last comment: in the case where I am able to reproduce the 
problem of the settings not being saved, I am *unable* to reproduce the symptom 
of setting the whitelist via the JMC -- with the  spamActionTargetAccount 
preference set incorrectly, nothing can be permanently changed on the JMC 
dialog.
*** Bug 210966 has been marked as a duplicate of this bug. ***
I wanted to disable Junk mail controls completely but failed - the OK button
does nothing.
You have to select a valid address book first even if you want to disable junk
mail controls!

My experience has been similar to many of the reports here.  Perhaps I can add
some additional clues to help the maintainers fix it.

I had been using Netscape 7.0 on Solaris 9 on a Sparc box before migrating to
Mozilla 1.7.  After trying to enable Junk Mail Controls, I too encountered
nothing after pressing the Okay button.  The user profile was inherited from
what Netscape 7.0 created.

What I finally did to get JMC working was to create a new user profile and
examine what it created in prefs.js.  Then I compaired it to the original
profile and found that a number of user_pref mail.server.serverX options were
missing.

It added:

user_pref("mail.server.server6.manualMark",
true);user_pref("mail.server.server6.moveOnSpam", true);
user_pref("mail.server.server6.moveTargetMode", 1);
user_pref("mail.server.server6.spamActionTargetAccount",
"mailbox://bluelnk%5Cdavid.c.mores@blums0010");
user_pref("mail.server.server6.spamActionTargetFolder",
"mailbox://bluelnk%5Cdavid.c.mores@blums0010/Trash");

I had to carefully modify the spamActionTarget* items to work with my original
profile.  Until these items are correctly configured, JMC will just not work. 
The main items to note here are that letting Mozilla work in a new profile
seemed to be the best way to correctly create working spamActionTarget* prefs,
and Mozilla does not seem able to recognize and add incomplete/missing user_pref
lines for JMC in an inherited profile.

I hope this is helpfull.
*** Bug 255635 has been marked as a duplicate of this bug. ***
*** Bug 217548 has been marked as a duplicate of this bug. ***
From the dupe, bug 217548 comment 3 reports an interesting JavaScript error when 
encountering this problem.
Product: MailNews → Core
*** Bug 324435 has been marked as a duplicate of this bug. ***
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Robyn writes: "using SeaMonkey 1.1.4 and it is not possible (as far as I can see) to have no address book selected under "Do not mark messages...."  Having no address book selected was the condition under which I saw the bug, so that bug is gone in this version of SeaMonkey."  Reporter appears to be gone, so ...
=> WFM
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.