Last Comment Bug 593807 - United Easy Check-in for customers outside of US not possible due to missing fields
: United Easy Check-in for customers outside of US not possible due to missing ...
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla2.0b10
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.united.com/page/middlepage...
: 596238 (view as bug list)
Depends on: 619220
Blocks: 515401
  Show dependency treegraph
 
Reported: 2010-09-06 06:33 PDT by Henrik Skupin (:whimboo) [away 09/30 - 10/06]
Modified: 2011-01-15 03:55 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 06:33:21 PDT
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.
Comment 1 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 06:37:11 PDT
Reported failure in the error console:

Error: getNonUSNationalInfo is not defined
Source File: https://travel.united.com/eco/webcheckin/altSearch.do
Line: 1
Comment 2 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 06:40:08 PDT
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.
Comment 3 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 07:17:54 PDT
Ok, the real regression happened between 10042303 and 100142403:

PASS: http://hg.mozilla.org/mozilla-central/rev/fe937d72a9ce
FAIL: http://hg.mozilla.org/mozilla-central/rev/d542ee95ef22

Check-ins:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fe937d72a9ce&tochange=d542ee95ef22
Comment 4 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 07:22:31 PDT
As talked with Henri on IRC this looks like to be a regression from bug 515401.
Comment 5 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 07:24:35 PDT
Using the inspector it shows that the base element has been added below the body element.
Comment 6 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2010-09-06 07:40:31 PDT
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>
Comment 7 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-06 07:57:52 PDT
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.
Comment 8 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-06 08:18:50 PDT
I contacted United via their customer service form. I hope the message finds the people responsible for the site.
Comment 9 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-07 01:16:47 PDT
The automated customer service first-response system at United gives a 10-day ETA for getting the first email response.
Comment 10 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-07 04:17:56 PDT
I posted to the HTML WG, too:
http://lists.w3.org/Archives/Public/public-html/2010Sep/0062.html
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2010-09-14 08:49:30 PDT
*** Bug 596238 has been marked as a duplicate of this bug. ***
Comment 12 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-20 06:54:16 PDT
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?
Comment 13 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-09-20 09:26:04 PDT
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?
Comment 14 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-22 07:25:33 PDT
(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.
Comment 15 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-11-28 23:50:41 PST
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.
Comment 16 Timothy Nikkel (:tnikkel) 2010-11-29 00:02:21 PST
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.
Comment 17 Timothy Nikkel (:tnikkel) 2010-12-07 12:47:53 PST
I got a response saying that they have forwarded the issue to their technology department.
Comment 18 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2011-01-15 03:55:07 PST
Bug 619220 fixed this in a non-evang way.

Note You need to log in before you can comment on or make changes to this bug.