Closed Bug 480206 Opened 12 years ago Closed 11 years ago

virginamerica.com -- flight search dropdown doesn't work

Categories

(Tech Evangelism Graveyard :: English US, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: fligtar)

References

()

Details

Attachments

(1 file)

I noticed this a few weeks ago, but didn't realize until now that it was a recent regression.  The main way of accessing the Virgin America Web site isn't working on mozilla-central builds.

Steps to reproduce:
 1. go to http://www.virginamerica.com/
 2. click on the "Search Flights" text (the biggest text in the page, along the left edge a little below the top)

Expected results: section with flight search opens up below the words "Search flights"

Actual results:  nothing

This regressed between mozilla-central Linux x86_64 builds 2009-01-13-03-mozilla-central and 2009-01-14-01-mozilla-central which gives (based on the SourceStamp in their application.ini files) a regression range of http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a7274359673d&tochange=89811ac1b35a

It still works correctly in mozilla-1.9.1 builds.
Flags: blocking1.9.2?
There are a bunch of JS errors in the error console in broken builds, but none in working builds.  They are:

Error: setting a property that has only a getter
Source File: http://www.virginamerica.com/va/scripts/GlobalScriptFile_02242009.js
Line: 1

Error: s is undefined
Source File: http://www.virginamerica.com/va/home.do
Line: 33

Error: init is not defined
Source File: http://www.virginamerica.com/va/home.do
Line: 722

Error: document.layers is undefined
Source File: http://www.virginamerica.com/va/scripts/GlobalScriptFile_02242009.js
Line: 1

Error: s is undefined
Source File: http://www.virginamerica.com/va/home.do
Line: 3895
I looked at the script, and they're setting the readyState property on a document, which makes me think that the property in question that has only a getter is readyState.  (That error message could be more useful, though.)  That would make this likely a regression from bug 347174.

Shouldn't new DOM properties like that be settable by the page, for compatibility?
Blocks: 347174
Component: General → DOM
QA Contact: general → general
So jst and mrbkap tell me this is a tech evangelism bug.

http://www.virginamerica.com/va/scripts/GlobalScriptFile_02242009.js contains JS code from a framework that's doing:

if(_SARISSA_IS_IE) {
   // a bunch of stuff
} else {
   // a bunch of stuff including implementing document.readyState by hand
}

IE7 gives a JS error when setting document.readyState (try the attached test, and see whether you get one or two alerts), and now so do we.
Assignee: nobody → english-us
Component: DOM → English US
Flags: blocking1.9.2?
Product: Core → Tech Evangelism
QA Contact: general → english-us
Version: Trunk → unspecified
OS: Linux → All
Hardware: x86 → All
Summary: dropdown sections on virgin america Web site don't work → virginamerica.com -- flight search dropdown doesn't work
Duplicate of this bug: 483648
Duplicate of this bug: 499038
I have the same issue using Oracle/Hyperion Workspace, unable to show external access site to show this although can load application.js file if required.

Confirmed issue on Solaris & Mac.
comment 7 doesn't belong on this bug report, since this bug is specific to virginamerica.com.
Filed Bug 508563 for the Oracle/Hyperion Workspace issue.
The way Virgin America should fix this is change the code mentioned in comment 4 so that it doesn't try to implement document.readyState by hand when the browser already implements document.readyState.
(sucks I can't use Firefox to book flights)
mrz, i think it should work on Fx 3.5.6.  at least the landing page.   the problem reported is more on nightly builds
This is on 3.6b5 :|
yes, thats cause 3.6b5 is still an unsupported release for virginamerica.   Firefox 3.5.6 is what i'm talking about.
The original report here is about a problem that was triggered by a new feature in Fx3.5 (relative to Fx3.0).
Seems like they've finally fixed the site.
So, do we need to a file separate bug for the 3.6b5 problem then? I can't use the site in 3.6b5 either, but it does work in 3.5.6.
(In reply to comment #15)
> The original report here is about a problem that was triggered by a new feature
> in Fx3.5 (relative to Fx3.0).

Oops, I was getting things confused.  It is a new feature in Fx3.6 (relative to Fx3.5); in comment 0 I said "it still works correctly in mozilla-1.9.1 builds".

(In reply to comment #16)
> Seems like they've finally fixed the site.

So, what I was seeing actually wasn't a change in the site.  It turned out that it started working again between mozilla-central nightlies (Linux x86_64) 2009-12-20-03 and 2009-12-21-03, giving the checkin range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4e23cc1f527&tochange=88ee36d9eb53

I think it was probably fixed by bug 529404, which made the problematic assignment no longer be an error.
Depends on: 529404
Also confirm it's working for mac osx and solaris (x86) versions of 3.7a1.
(In reply to comment #17)
> So, do we need to a file separate bug for the 3.6b5 problem then? I can't use
> the site in 3.6b5 either, but it does work in 3.5.6.

dont think you need another bug.  this bug was tracking the problem overall and already assighned to TE.   comment 9 includes the regression range.
> (In reply to comment #17)
 comment 9 includes the regression range.

oops i meant comment 18
The site still doesn't work in the latest 3.6 RC. Does this being assigned to TE mean we're saying it's their problem and I should try to contact someone at their website to tell them they're doing something wrong? If so, please tell me what they're doing wrong and I will gladly try to contact them.

I thought that it's our problem since it's a regression, and we need to get the fix from trunk to 3.6.

It's not like this is an obscure site -- the main use case of the website of an increasingly large airline is completely broken in Firefox 3.6.
Justin: it looks like comment 18 explains why this suddenly works in mozilla-central builds. It seems as though they need to fix comment 1 through comment 4 in order to be maximally compatible with Firefox 3.6 (Gecko 1.9.2). As I understand it, Gecko 1.9.1 and earlier builds don't have the problem, and neither do Gecko 1.9.3 and later builds.

dbaron: can you confirm that for me?
Yeah, this is their problem.  They're assuming that any non-IE browser doesn't implement document.readyState; in 1.9.1 and earlier we don't implement it; in 1.9.3 we don't give errors when writing to a readonly property.
Not sure users will understand it's virgin's issue to fix (or care).  Any sort of outreach I can help with?
Thanks -- comment #24 helped me understand the issue. I contacted VX's tech team just now and mentioned the 3.6 release date, so hopefully they can get it fixed tomorrow. I'll post any updates from them here.
Assignee: english-us → fligtar
Status: NEW → ASSIGNED
I contacted them a few weeks ago as well, customer service saying they had transferred my email to the website team. But no improvment yet...
New website online, the bug is not present anymore. May somebody close it?
Yeah, looks like the new virginamerica.com works fine.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.