Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100905 Firefox/4.0b6pre
As a customer outside of the U.S. you are not able to check-in on the united.com website anymore. This is a regression in Firefox 4.0.
1. Log-in by using the above specified URL
2. Scroll down to the nationality drop down
3. Select another nationality as U.S
After step 3 a set of other fields (visa, address, and others) should appear below the nationality dropdown. But nothing is displayed anymore.
Could be similar to bug 588462 which regressed in the same window:
Regression range between 10050303 and 10050403.
This regression is caused by bug 373864 which enabled the html5 parser by
The latest fix on bug 585819 doesn't solve this issue.
Reported failure in the error console:
Error: getNonUSNationalInfo is not defined
Source File: https://travel.united.com/eco/webcheckin/altSearch.do
Btw. with the HTML5 parser enabled in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:126.96.36.199) Gecko/20100722 Firefox/3.6.8 everything works fine.
Looks like I should find a better regression range.
Ok, the real regression happened between 10042303 and 100142403:
As talked with Henri on IRC this looks like to be a regression from bug 515401.
Using the inspector it shows that the base element has been added below the body element.
Using Cmd+U to check the code shows the following:
<link rel="stylesheet" type="text/css" href="/web/common/css/alciOptions.css" />
<c:set var="static_c2c" value="true" scope="request"/>
The reason why this works in IE8 is that in IE tags with colons in their names don't implicitly close head and open body and tags with colons in their names behave as self-closing if they end with />.
The above markup behaves in IE9's IE9 mode just like it behaves in Firefox nightlies. (But the IE9 mode probably won't be activated for united.com...)
The old parser plus bug 515401 takes the <base> into account, because the old parser hoists <base> into <head> even if it is seen in <body>.
Chromium nightlies take the <base> into account, because WebKit doesn't appear to have a fix equivalent to our bug 515401 yet.
I think we should try contacting the site as the first action item.
I contacted United via their customer service form. I hope the message finds the people responsible for the site.
The automated customer service first-response system at United gives a 10-day ETA for getting the first email response.
I posted to the HTML WG, too:
*** Bug 596238 has been marked as a duplicate of this bug. ***
Ten days have passed without a response from United.
sicking, are you OK with treating this as a Gecko and spec bug and honoring the first <base href> in the doc for base URL and the first <base target> in document for the default target browsing context?
I'm not so worried about United. We have traditionally had a hard time getting sites to care until we do the final release, and 10 days isn't that long of a time.
The other sites you mentioned in the HTML WG email is more concerning. Is there any way to gauge how much it's used on the public web, i.e. can it be googled for?
(In reply to comment #13)
> I'm not so worried about United. We have traditionally had a hard time getting
> sites to care until we do the final release, and 10 days isn't that long of a
What do we win by taking only the first <base> in head into account instead of taking the first <base> in the document into account?
> The other sites you mentioned in the HTML WG email is more concerning. Is there
> any way to gauge how much it's used on the public web, i.e. can it be googled
Someone at Google could run an analysis, but I think it can't be measured using normal Google search.
It seems to me that my attempt to contact United went to /dev/null. Assigning away from me to indicate that others should feel free to try to contact United.
Since I'm an actual United customer who is affected by this I used their web form to send a message about this. Who knows if it will lead anywhere.
I got a response saying that they have forwarded the issue to their technology department.
Bug 619220 fixed this in a non-evang way.