Closed
Bug 24681
Opened 25 years ago
Closed 25 years ago
[Activation] Can't launch after turning the activation prefs on (true, www.my.netscape.com)
Categories
(Core Graveyard :: Profile: BackEnd, defect, P1)
Tracking
(Not tracked)
M14
People
(Reporter: kevinyen, Assigned: racham)
References
Details
(Whiteboard: [PDT+])
No description provided.
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.
Status: NEW → ASSIGNED
Just adding [Activation] to Activation bugs.
Summary: Can't launch after turning the activation prefs on (true, www.my.netscape.com) → [Activation] Can't launch after turning the activation prefs on (true, www.my.netscape.com)
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!
Whiteboard: [PDT+]
Added silent profile creation in the activation path. Should be able to do this
now. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Adding comments on wait for verification to Status Summary
Whiteboard: [PDT+] → [PDT+] Need 01/28 build to verify
Comment 6•25 years ago
|
||
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
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: FIXED → ---
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
Status: REOPENED → NEW
Priority: P3 → P1
Whiteboard: [PDT+] Need 01/28 build to verify → [PDT+]
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.
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 10•25 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 11•25 years ago
|
||
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.
Assignee | ||
Comment 12•25 years ago
|
||
Just tested with the latest build posted. It works fine. Marking worksforme.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Comment 13•25 years ago
|
||
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?
Assignee | ||
Comment 14•25 years ago
|
||
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.
Assignee | ||
Comment 15•25 years ago
|
||
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 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•