193984 - Mozilla and Travelocity do not play well together.

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect, P3)

Description

[david]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210

Browser does not render the flight search list at all well.  Symptoms vary, but
include side bar 3X wider than it should be, large blocks of white space prior
to flight list, improper text wrap, and more.

Reproducible: Always

Steps to Reproduce:
1. Go to travelocity.com
2. Under 'Find the best airfare', enter two cities and select 'My dates are
flexible'
3. Click Search Now.

Actual Results:  
Browser does not render the flight search list at all well.  Symptoms vary, but
include side bar 3X wider than it should be, large blocks of white space prior
to flight list, improper text wrap, and more.

Expected Results:  
Should match Internet Explorer.  Netscape 6.2 also fails.

Frankly, I don't know if this is a bug or IE specific coding on the web site.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Every time it fails (it's intermittent) there's an extra table in the source
with "name=error_table" and the div with the searches is moved to after this
table (out of the table it should live in).  When it succeeds, this extra table
is _not_ in the source and the div is in the right place.

So this certainly sounds like a server bug (the source is just totally different
when it fails).

Comment 2

[david]

Hmmm... it's happening every time here.  I'm using tabbed browsing and I usually
put Travelocity on the second tab when making airline reservations (united.com
on the first tab).  Don't know if that makes a difference.

I'm inclined to agree with you on the server side bug, but the fact that IE gets
it right makes me suspect some weird Microsquish logic at work here.  I did a
View/Source and (while no html giant) I don't understand why an empty table
should cause such rendering grief.

Failing any technical solution, does the issue become how to alert Travelocity
that Netscape (& AOL?) & Mozilla can't use their site reliably?  Or is it a
place where special case logic needs added to Gecko?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> I don't understand why an empty table should cause such rendering grief.

The problem is no the empty table but the fact that the <div> with all the
content is moved.  So the markup changes from:

---------------------------------
<table>
<tr>
<td>sidebar</td>
<td><div>content</div></td>
</tr>
</table>
---------------------------------

to

---------------------------------
<table>
<tr>
<td>sidebar</td>
<td></td>
</tr>
</table>

<table name=error_table>
</table>

<div>
content
</div>
---------------------------------

See where the rendering grief comes from?

If this turns out to not be triggered by a gecko bug, it should be reassigned to
the Tech Evangelism product (and it would be great if you would mail travelocity
and let them know of the problem as a user of the service).

Comment 4

[david]

I decided to check browser behavior today; here are the results:

Runs:
- Netscape 4.51 (RH 6.0) & 4.73 (Win2K)
- IE 5.0 (Win2K) & 6.0 (WinXP)
- Mozilla 1.0.1 (RH 7.3)
- Konqueror 3.0.3 (RH 7.3)

Fails:
- Netscape 6.2 (WinXP)
- Mozilla 1.3a & 1.3b (WinXP)

Untested:
- Opera
- Mozilla 1.2

This is not a strong case for Travelocity to change their html, and seems to
point back to the rendering engine.  

Comment 5

[Boris Zbarsky [:bzbarsky]]

You're assuming they serve all the browsers involved the same HTML.  I've just
tried loading the page in Netscape 4 ten times in a row and not _once_ did the
HTML have the extra table or the moved div.

Like I said, it could still be a Mozilla issue (cookies or something).  But I
have no clever ideas yet on how to test it.... maybe use the UABar to spoof the
Netscape or IE user-agent?

Comment 6

[Andrew Schultz]

*** Bug 183602 has been marked as a duplicate of this bug. ***

Comment 7

[Andrew Schultz]

Runs:
- Mozilla 1.0.1 (RH 7.3)

Fails:
- Netscape 6.2 (WinXP)
- Mozilla 1.3a & 1.3b (WinXP)

6.2 is based on very old code while 1.3x is very new code.  1.0.1 is in the
middle.  are you sure 1.0.1 didn't have the problem?  are you testing with clean
profiles?

Comment 8

[david]

Things took a turn for the weird here for a couple minutes, because I started
getting failures in Mozilla 1.0.1 too.  Then I realized it worked on one Linux
system and not the other.  Same version number, different Gecko release.  Here's
the chart:

Works:
- RH7.3 base Mozilla 0.9.9/Gecko 20020513
- RH8.0 base Mozilla 1.0.1/Gecko 20020830

Fails:
- RH7.3 upgd Mozilla 1.0.1/Gecko 20021003
- WinXP strd Mozilla 1.2.1/Gecko 20021130
- WinXP test Mozilla 1.3b /Gecko 20030210

I keep the RH7.3 upgd system fairly current with security patches, which is why
it's had changes applied.  RH8.0 has not been patched yet, or it probably would
display the problem as well.

Comment 9

[James]

Another possibley symptom:

The select date window for picking dates is a fixed size window and does not
size properly when using Mozilla, but works correctly in IE.  I used tab
browsing, and this has occured in Mozilla 1.2 and 1.3 final.

Comment 10

[tom.williams]

Attachment: Screenshot of Travelocity page in Mozilla 1.4b

This problem looks like it's been fixed in Mozilla 1.4b.  I'm using Mozilla/5.0
(Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030406 and I did a search on
flights leaving from San Jose, CA to Denver, CO on May 4 and returning on May
9.  The result was a multi-page (if printed) list of flights and everything
looked great!  I've attached a screenshot of the first page of output.	The
rest of the table goes straight down and is formatted excellently.

Great work!  :)

Peace....

Comment 11

[Bharat]

Travelocity has changed the page that it serves up, and this problem is no
longer there. Marking WFM (tested with Mozilla 1.5 on WinXP).

Reporter, if you feel that this bug has been closed in error, please reopen.

Comment 12

[Andrew Schultz]

*** Bug 231296 has been marked as a duplicate of this bug. ***

Comment 13

[Andrew Schultz]

I'm still seeing this bug (along with Eric from 231296)

Reopening.

Comment 14

[Andrew Schultz]

I'm still seeing this bug (along with Eric from 231296)

Reopening.

Comment 15

[Andrew Schultz]

I managed to get this bug to happen loading locally.  Sometimes is shows up, and
sometimes it doesn't (with the same html).

When it shows up, DOM Inspector shows that the flight tables at the bottom that
are too far to the left are not inside the parent table.  When the display is
ok, the tables are properly included in the parent table.

==> parser

Comment 16

[Boris Zbarsky [:bzbarsky]]

Andrew, see comment 1 and comment 3.  If you're getting this to happen locally
with some specific HTML, please attach said HTML to this bug, ok?

Comment 17

[Andrew Schultz]

Attachment: html page exhibitting the bug

this is just the html page as delivered by travelocity.  With linux trunk
20040117, it displays ok sometimes and sometimes has the last 3 flights flush
left.  In that case, DOM Inspector shows them as tables outside their parent
table.	To load this page, I'm using a PHP script that serves up the page a
single byte at a time (it loads fine as just a local file).  But it might also
exhibit the bug loading from bugzilla.

Replacing the <script>...</script> at the top with:
<script>
<!--
//-->
</script>

gives a page that has *everything* below "> Select an Airline" at the bottom of
the page, flush left (when loaded with the PHP script).  Adding a single JS
comment within the SCRIPT moves everything back into place.

Comment 18

[Ski]

As of September 2004, the "flush left" problem is still there. I see this behavior
in FireFox 0.9.3 :(

Comment 19

[tom.williams]

Attachment: Screenshot of incorrect page rendering

This new screenshot is how a Travelocity page rendered in Mozilla/5.0 (Windows;
U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1.

I'll try to attach the HTML in question if I can.

Peace...

Comment 20

[tom.williams]

Attachment: ZIP file with HTML of incorrectly rendering page

Ok, this attachment is the complete HTML page which resulted in the 161068
screenshot.

Peace...

Comment 21

[Henri Sivonen (:hsivonen)]

Attachment 161073 [details] looks bad in Opera and Chrome, too, but the live Travelocity site seems fixed. Marking WFM.