Closed Bug 593807 Opened 14 years ago Closed 13 years ago

United Easy Check-in for customers outside of US not possible due to missing fields

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b10

People

(Reporter: whimboo, Unassigned)

References

()

Details

(Keywords: regression)

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.

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

PASS: http://hg.mozilla.org/mozilla-central/rev/83c887dff0da
FAIL: http://hg.mozilla.org/mozilla-central/rev/d6bb0f9e9519

Check-ins:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519

This regression is caused by bug 373864 which enabled the html5 parser by
default. 

The latest fix on bug 585819 doesn't solve this issue.
blocking2.0: --- → ?
Reported failure in the error console:

Error: getNonUSNationalInfo is not defined
Source File: https://travel.united.com/eco/webcheckin/altSearch.do
Line: 1
Btw. with the HTML5 parser enabled in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 everything works fine.

Looks like I should find a better regression range.
As talked with Henri on IRC this looks like to be a regression from bug 515401.
Blocks: 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"/>

<html>

<head>
    <base href="https://travel.united.com/eco/webcheckin/secureflight/sfIntlPaxInfo.jsp">

     <title>
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.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Component: HTML: Parser → English US
Product: Core → Tech Evangelism
QA Contact: parser → english-us
Version: Trunk → unspecified
The automated customer service first-response system at United gives a 10-day ETA for getting the first email response.
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
> time.

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
> for?

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.
Assignee: hsivonen → english-us
Status: ASSIGNED → NEW
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.
Assignee: english-us → nobody
Component: English US → General
Product: Tech Evangelism → Firefox
QA Contact: english-us → general
Assignee: nobody → english-us
blocking2.0: ? → ---
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
Bug 619220 fixed this in a non-evang way.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 13 years ago
Component: English US → DOM: Core & HTML
Product: Tech Evangelism → Core
QA Contact: english-us → general
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
You need to log in before you can comment on or make changes to this bug.