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

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: test page showing whether setting document.readyState gives an error

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Iain Curtain]

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 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

comment 7 doesn't belong on this bug report, since this bug is specific to virginamerica.com.

Comment 9

[Ginn Chen]

Filed Bug 508563 for the Oracle/Hyperion Workspace issue.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 11

[matthew zeier [:mrz]]

(sucks I can't use Firefox to book flights)

Comment 12

[Tony Chung [:tchung]]

mrz, i think it should work on Fx 3.5.6.  at least the landing page.   the problem reported is more on nightly builds

Comment 13

[matthew zeier [:mrz]]

This is on 3.6b5 :|

Comment 14

[Tony Chung [:tchung]]

yes, thats cause 3.6b5 is still an unsupported release for virginamerica.   Firefox 3.5.6 is what i'm talking about.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The original report here is about a problem that was triggered by a new feature in Fx3.5 (relative to Fx3.0).

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Seems like they've finally fixed the site.

Comment 17

[Justin Scott [:fligtar]]

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.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.

Comment 19

[Iain Curtain]

Also confirm it's working for mac osx and solaris (x86) versions of 3.7a1.

Comment 20

[Tony Chung [:tchung]]

(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.

Comment 21

[Tony Chung [:tchung]]

> (In reply to comment #17)
 comment 9 includes the regression range.

oops i meant comment 18

Comment 22

[Justin Scott [:fligtar]]

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.

Comment 23

[Chris Lawson (gone)]

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?

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 25

[matthew zeier [:mrz]]

Not sure users will understand it's virgin's issue to fix (or care).  Any sort of outreach I can help with?

Comment 26

[Justin Scott [:fligtar]]

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.

Comment 27

[Mathieu Marquer]

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...

Comment 28

[Mathieu Marquer]

New website online, the bug is not present anymore. May somebody close it?

Comment 29

[Justin Scott [:fligtar]]

Yeah, looks like the new virginamerica.com works fine.