virginamerica.com website crashes FF

[onix]

Virgin America's newly redesigned website causes an unresponsive script, hangs my Firefox (latest version 30.0) for more than 10 seconds, and then often goes on to crash FF. The site will not work unless BOTH levexis.com and librato.com are allowed. librato is a marketing tracking company. levexis based out of the UK is not accessible on a browser.

Anyone else with the same problem? I also use the AdBlock Plus extension.

TAGS: Virgin America website not working Firefox NoScript crash stall hang load

[barbaz]

Code: Select all

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: https://www.virginamerica.com/scripts/vx.min.js:5

Doesn't seem to matter the NS version, I'm seeing that in SeaMonkey 2.27a2 (like Firefox 30.0a2). Didn't try any other browsers.
Got that after only temp-allowing the top-level site (didn't bother to allow those other sites you mentioned).

Line 5 is really long, no time to sort through that mess to identify the culprit

ETA This does *not* happen with NS disabled.

The site will not work unless BOTH levexis.com and librato.com are allowed.

Actually, both of those domains would appear to be the sort of site for which NS should provide surrogate scripts.

@onix: I would suggest sanitising links of that nature in future (either check the "Do not automatically parse URLs" box below the posting area, or wrap the link in

Code: Select all

 tags).

[barbaz]

ok, its just really stupid site design. if I fake an IE10/Win7 user agent then it's working normally in SeaMonkey 2.27a2 with NS enabled and only the top-level domain temp-allowed. also no requests are made to this librato domain.

about:config -> create string pref

Code: Select all

general.useragent.override.virginamerica.com

set value to

Code: Select all

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C)

Does that help?

[onix]

Well, that seems like a hack and may then result in site un-functionality. Where user input like flight selection, seat selection, credit card info is required, it would suck if the process failed somewhere downstream right before the purchase.

Is VA discriminating against FF users with NS??

[onix]

OK, I added the pref in about:config. Didn't work. Thanks for suggesting.

[barbaz]

Well, that seems like a hack and may then result in site un-functionality.

to note, just reset that pref and reload the page to completely undo

Is VA discriminating against FF users with NS??

Somehow I doubt that. (I didn't have a Firefox/Gecko user-agent during the tests in my second post )

It might be worth contacting VA, pointing them to this thread, and letting them know this is happening. Please tell us what they say and if it gets fixed.

[therube]

general.useragent.override.virginamerica.com

I believe FF removed that feature from their end, yes, go figure.
Bug 896114 - UserAgentOverrides take ~9% of pageload time on a smugmug gallery
(Ratty had said, that we have seemingly picked up the fixes such that we should not be impacted.)

[therube]

Virgin America's newly redesigned website causes an unresponsive script, hangs my Firefox (latest version 30.0) for more than 10 seconds, and often crashes FF.

That is some awful behavior!

[barbaz]

if I stop the script, these messages show in the Error Console

Code: Select all

Warning: Error: Script terminated by timeout at:
n@https://www.virginamerica.com/scripts/vx.min.js:5:4259
a.prototype._send@https://www.virginamerica.com/scripts/vx.min.js:14:5593
a.prototype.pushFailure@https://www.virginamerica.com/scripts/vx.min.js:14:5186
b/<.responseError@https://www.virginamerica.com/scripts/vx.min.js:7:21818
Ac/h/g.promise.then/l@https://www.virginamerica.com/scripts/vx.min.js:5:19712
Ac/k/<.then/<@https://www.virginamerica.com/scripts/vx.min.js:5:20487
Cc/this.$get</k.prototype.$eval@https://www.virginamerica.com/scripts/vx.min.js:5:25535
Cc/this.$get</k.prototype.$digest@https://www.virginamerica.com/scripts/vx.min.js:5:24051
Cc/this.$get</k.prototype.$apply@https://www.virginamerica.com/scripts/vx.min.js:5:25865
i@https://www.virginamerica.com/scripts/vx.min.js:5:4878
r@https://www.virginamerica.com/scripts/vx.min.js:5:7222
_b/</w.onreadystatechange@https://www.virginamerica.com/scripts/vx.min.js:5:7777

Source File: https://www.virginamerica.com/scripts/vx.min.js
Line: 5



Error: Error: [$rootScope:inprog] $digest already in progress
http://errors.angularjs.org/1.2.18/$rootScope/inprog?p0=%24digest
Source File: https://www.virginamerica.com/scripts/vx.min.js
Line: 4

the problem appears to be the way librato is loaded. if librato is forbidden, I get the warning. if I temp-allow it, no warning.
that would explain why using a MSIE10 useragent appeared to "fix" the problem (no librato).

these are the requests being made to librato (only happens if librato is (temp-)allowed)

Code: Select all

referer  method  destination
(none) OPTIONS https://metrics-api.librato.com/v1/metrics
(none) OPTIONS https://metrics-api.librato.com/v1/metrics
(none) OPTIONS https://metrics-api.librato.com/v1/metrics
https://www.virginamerica.com/ POST https://metrics-api.librato.com/v1/metrics
https://www.virginamerica.com/ POST https://metrics-api.librato.com/v1/metrics

according to adblock plus, they are xhr.

Is this a NoScript bug or something NoScript should work around?