Mozilla and Travelocity do not play well together.




HTML: Parser
15 years ago
8 years ago


(Reporter: david, Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)




(4 attachments)



15 years ago
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
2. Under 'Find the best airfare', enter two cities and select 'My dates are
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.
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

15 years ago
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 (
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?

> 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 name=error_table>


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

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

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

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

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

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

Comment 7

15 years ago
- Mozilla 1.0.1 (RH 7.3)

- 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

Comment 8

15 years ago
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:

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

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


15 years ago
Priority: -- → P3

Comment 9

15 years ago
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

15 years ago
Created attachment 120080 [details]
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!  :)


Comment 11

15 years ago
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.
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 12

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

Comment 13

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


Comment 14

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

Resolution: WORKSFORME → ---

Comment 15

14 years ago
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
Assignee: core.layout → parser
Component: Layout → HTML: Parser
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

14 years ago
Created attachment 139373 [details]
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:

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.


14 years ago
Ever confirmed: true
Keywords: testcase

Comment 18

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

Comment 19

14 years ago
Created attachment 161068 [details]
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.


Comment 20

14 years ago
Created attachment 161073 [details]
ZIP file with HTML of incorrectly rendering page

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

Assignee: parser → nobody
QA Contact: ian → parser
Attachment 161073 [details] looks bad in Opera and Chrome, too, but the live Travelocity site seems fixed. Marking WFM.
Last Resolved: 15 years ago8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.