Unable to create new account on www.hotmail.com .

VERIFIED FIXED

Status

Tech Evangelism Graveyard
English US
--
major
VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: Teodosia Pop, Assigned: hsivonen)

Tracking

({regression})

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101102 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101102 Firefox/4.0b8pre

After I complete all the forms form the "Sign up" page and submit my info, the account is not created, even if all the info is correct. Also, I am being redirected to the "Sign up" page without any confirmation or error page,

Reproducible: Always

Steps to Reproduce:
1.Got to http://www.hotmail.com
2.Click on the "Sign up" button.
3.Complete the required forms and click the "I accept" button.
Actual Results:  
I am redirected to the sign up page, without any confirmation or error message.

Expected Results:  
I should be redirected on a confirmation page if the account was created.

I've attached a print screen with the errors I get in the Error Console.
(Reporter)

Comment 1

7 years ago
Created attachment 487862 [details]
error console

Updated

7 years ago
Component: General → DOM
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Target Milestone: --- → mozilla2.0
Version: unspecified → Trunk

Comment 2

7 years ago
Regression Window:
Works:
http://hg.mozilla.org/mozilla-central/rev/268ef4ccb5ff
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre ID:20100917041014
Fails:
http://hg.mozilla.org/mozilla-central/rev/bc15c280c430
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre ID:20100917044206
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=268ef4ccb5ff&tochange=bc15c280c430
Blocks: 591981
blocking2.0: --- → ?
(Assignee)

Comment 3

7 years ago
Is it known what script ordering property Hotmail's account setup depends on (script-inserted external scripts maintaining order, script-inserted inline and external script maintaining order or script-inserted scripts blocking parser-inserted scripts)?

This is UA-sniffed code on Hotmail, right? The mozilla-central script ordering behavior should now match IE/Safari/Chrome.

Does Hotmail use LABjs or RequireJS?

Comment 4

7 years ago
If it is _not_ including "Firefox" in UA, the problem does _not_ occur.

i.e. set "general.useragent.override" to "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101102 Minefield/4.0b8pre" 


So, is this the site issue and Tech Evangelism?

Comment 5

7 years ago
Does NOT repro with UA:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre

OR
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100916 Minefield/4.0b7pre

Is this a regression for build 20101102?

Comment 6

7 years ago
(In reply to comment #5)
> Does NOT repro with UA:
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100916
> Firefox/4.0b7pre
> 
> OR
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100916
> Minefield/4.0b7pre
> 
> Is this a regression for build 20101102?
Regressed since ID:20100917044206
(Assignee)

Comment 7

7 years ago
If Hotmail is depending on script-inserted external scripts executing in insertion order, the problem wouldn't reproduce when the scripts *happen* to load in the insertion order. That might explain the contradictory findings.

That is, if you do
var s1 = document.createElement("script");
s1.src = "s1.js";
document.body.appendChild(s1);
var s2 = document.createElement("script");
s2.src = "s2.js";
document.body.appendChild(s2);

The nightlies, just like IE/Safari/Chrome, do NOT guarantee the evaluation order of s1.js and s2.js. Firefox 3.6 did. Bug 602838 has patches waiting for review. If/when those land, sites will be able opt into insertion order execution of script-inserted external scripts by setting .async=false on the script nodes before inserting them.

(In reply to comment #4)
> So, is this the site issue and Tech Evangelism?

Yes, in the sense that Gecko changed to spec-compliant behavior, which is also the behavior already exhibited by IE (since forever) and WebKit, so if the new behavior is causing problems, the logical assumption is that the site is UA sniffing instead of serving cross-browser-compatible code for everyone.
Blocks: 610917
(Assignee)

Comment 8

7 years ago
We'll have a nicer evang story once bug 602838 lands.
Assignee: nobody → english-us
Component: DOM → English US
Depends on: 602838
Product: Core → Tech Evangelism
QA Contact: general → english-us
Target Milestone: mozilla2.0 → ---
Version: Trunk → unspecified
(Assignee)

Updated

7 years ago
Assignee: english-us → hsivonen
Status: NEW → ASSIGNED
(Assignee)

Comment 9

7 years ago
This isn't about the relative order of script-inserted external scripts. I made a build that made script-inserted external scripts maintain order among themselves, but the signup still didn't work.

I suspect the site expects script-inserted external scripts to block subsequent parser-inserted scripts (something the IE and WebKit don't do).
(Assignee)

Comment 10

7 years ago
I experimented some more.

So far I don't have proof of the signup page depending on the relative order of script-inserted external scripts. On the contrary, the evidence suggests that the page is not depending on that, but I don't have conclusive proof.

I do have proof, though, that the page is indeed depending on script-inserted external scripts blocking subsequent parser-inserted scripts.

There are two cross-browser and HTML5-compatible ways to fix this:
 1) Using document.write("\u003Cscript src='foo.js'>\u003C/script>"); to insert the scripts that need to block the parser. The disadvantage is that when multiple scripts are loaded using this method in one go, the scripts won't load in parallel until bug 543062 is fixed.

 2) Simply loading all the necessary scripts by putting <script src="foo.js"></script> tags in the page source. This is the most performant alternative, since Firefox will start fetching the scripts earlier.
(Assignee)

Updated

7 years ago
Blocks: 610917
(Assignee)

Updated

7 years ago
No longer blocks: 610917
(Assignee)

Comment 11

7 years ago
(In reply to comment #10)
> The disadvantage is that when
> multiple scripts are loaded using this method in one go, the scripts won't load
> in parallel until bug 543062 is fixed.

Bug 543062 is now fixed, so that's no longer a problem.
(Assignee)

Comment 12

7 years ago
Microsoft has a fix for this internally. I'll leave this bug open until the fix has been deployed.
Component: English US → General
Product: Tech Evangelism → Firefox
QA Contact: english-us → general
blocking2.0: ? → ---
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
(Assignee)

Comment 13

6 years ago
It looks like Microsoft has deployed the fix. Thank you!
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Verified on 

Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.