24681 - [Activation] Can't launch after turning the activation prefs on (true, www.my.netscape.com)

Status: VERIFIED DUPLICATE of bug 26716

(Core Graveyard :: Profile: BackEnd, defect, P1)

Comment 1

[racham]

This is tied up with the creation of a default profile, if no profile is found.
Will create a new profile so that the shell can launch urls.

Comment 2

[kevinyen]

Just adding [Activation] to Activation bugs.

Comment 3

[leger]

Putting on pdt+ radar for beta1.

Activation needs to be on in commercial builds ASAP.  gbush, make sure this is a 
testcase to ensure works for beta blessing..thanks!

Comment 4

[racham]

Added silent profile creation in the activation path. Should be able to do this 
now. Marking fixed.

Comment 5

[leger]

Adding comments on wait for verification to Status Summary

Comment 6

[Grace Bush]

pref("browser.registration.enable", true);
pref("browser.registration.url", "http://my.netscape.com");

I set these prefs for testing-crash on launch with no 5.0 profiles - using 
mozilla as command (no options)
Default profile gets created 

Comment 7

[kevinyen]

This is still broken.

When I turn on the Activation prefs (true, "www.my.netscape.com") and create a 
new profile, the new profile crashes when I launch the profile/seamonkey.

Changed priority to P1.  We need this working ASAP so NC can test.

thx,
kevin

Comment 8

[racham]

This is because the cookies service was not initialized and the server was 
trying Set-Cookie. This fix is in my local build. I shall check it in today. 
Toomany regressions and new bugs are coming up with no relavant changes made to
the code. Anyway, this fix should be in.

Comment 9

[racham]

This happened because of security code return values. Norris has checked in 
fixes for this to work. Url http://my.netscape.com can be loaded in the preg 
window now. Marking fixed.

Comment 10

[Grace Bush]

if pref("browser.registration.url", "http://my.netscape.com");
is used, launching activation still crashes.
pref("browser.registration.url",http p://seaspace/racham/PReg/prodreg.html");
works and does not crash.

Comment 11

[racham]

Grace,

The build you have tested with was posted at around 11.30 am yesterday.
The fix went in around 4 pm. So, we should not see this if we get a build
today. I am leaving this bug in reopen status for now. Once the new build
comes, we will test this and close it.

Comment 12

[racham]

Just tested with the latest build posted. It works fine. Marking worksforme.

Comment 13

[Grace Bush]

Bhuvan,

on build 2000020410, if I use this URL, activation screens do not appear- only 
my.netscape.com
I expected to see activation screens and then my.netscape.com after activation?  
Which is correct?

Comment 14

[racham]

The activation url supplied to us for beta is 

http://ureg-beta.netscape.com/activation/en/activation.cgi which inturn gets 

redirected to 

http://ureg.netscape.com/iiop/UReg2/reg/register?U2_ENDURL=http://ureg-beta.nets
cape.com:80/activation/en/activation.cgi?action=end&U2_EXITURL=http://ureg-beta.
netscape.com:80/activation/en/end.html?result=cancel&U2_SOURCE=ACTIVATION&U2_LA=
en&U2_CS=ISO-8859-1

The profile manager code simply takes the url from the prefs and creates a url 
object and loads it inthe webshell. Simple urls with no redirect gets loaded 
fine. So, I opened a bug against NECKO (bug 26716) to enable the ablity of 
redirect so that testing can happen with Netcenter's ureg server.

Reopening this bug and making it dependent on the bug 26716. 

Comment 15

[racham]

Just making this a dup of 26716 as I think no further changes are required to 
profile manager code in loading the page with UREG url.

*** This bug has been marked as a duplicate of 26716 ***

Comment 16

[Grace Bush]

verified- working now that dupe is working