195928 - popup blocking: need to provide path for previous release

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, enhancement)

Description

[sairuh (rarely reading bugmail)]

due to bug 195924, we will need to provide an "upgrade path" for previous users
of popup blocking who employed blacklisting. this would involve:

a. somehow informing users (eg, of nscp7.01 or nscp7.02) when they first use a
trunk build.

b. clearing out (via backend) their blacklist.

c. documenting this in help or relnote?

Comment 1

[sairuh (rarely reading bugmail)]

just remembered from triage mtg: we should do this at runtime, not with the
installer.

Comment 2

[shliang]

on second thought, i am not sure we should clear out their blacklist because 
they could just go back to an earlier build and make one again. then we would 
have to check every time to see if we need to clear it out again. maybe we 
should just keep the blacklist there but just not use it?

Comment 3

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 4

[shliang]

resolving

Comment 5

[sairuh (rarely reading bugmail)]

tested with 2003.03.27 commercial builds on win2k, mac 10.2.4 and linux rh8.0.
used profiles created with:

a. ns7.0rtm (has no blocking)
b. ns7.02rtm blocking w/blacklist (just ignored)
c. ns7.02rtm blocking w/whitelist
d. ns7.02rtm with no blocking

all of these scenarios worked fine, except for (b). here's a detailed test for a
profile using a blacklist.

1. with ns7.02, creat a profile which has "allow popups" and uses a blacklist.
(for simplicity, i cleared out the default whitelist as well.) here's what i had
in the blacklist:

netscape.com
resfest.com
hopey.mcom.com

2. quit and restart the profile using today's trunk (for me, commercial) build.

3. visit http://hopey.mcom.com/tests/unreqested-popup.html. results: the
notification icon appears in the status bar. however if i open the prefs panel,
"block unrequested popups" is deselected. (don't change the pref, though.)

4. visit http://resfest.com. a popup appears, and then i get the About Popups
dialog asking me whether i want to enable blocking.

5. click No in About Popups.

6. quit and restart profile in ns7.02.

7. view the blacklist.

results: upon returning to 7.02, the blacklist was cleared out. but why wasn't
it cleared before or at step 3?

[side note: if http://home.netscape.com was loaded at step 3 or 4, its popups
would *not* be blocked, or result in the About Popup dlg. since it'd be part of
the default whitelist, would this be expected anyhow?]

i'm reopening for this case --however, let me know if it should be spun off
separately.

Comment 6

[shliang]

oh. the blacklist is cleared out the first time the pref panel is loaded, so if
you don't go to prefs first that will happen. we had discussed clearing it out
at a different point but in the end decided to just leave it there. i guess it
does seem kinda odd now...

sarah, could you close this bug and open another one on moving the blacklist
clearing function somewhere else, maybe the first time we start up, rather than
leaving it until the first time someone goes to prefs. 

Comment 7

[sairuh (rarely reading bugmail)]

sure, spun off bug 199561.

Comment 8

[sairuh (rarely reading bugmail)]

and verifying.