- Redirect problem on United Airlines site.



Tech Evangelism Graveyard
English US
17 years ago
3 years ago


(Reporter: jst, Assigned: /\/\arcio Galli)




(Whiteboard: [bugscape 10984], URL)


(1 attachment)



17 years ago
Load the above URL and type in the flight number 946 in the flight status field
and press the Check button, the browser goes off to a page that says "Please
wait while we retrieve the flight information you requested." and gets stuck
there. In IE it goes to the same page but after less than a second it loads the
page with the flight status on it.

Comment 1

17 years ago
Upping the severity to critical given that this is a major site
Severity: normal → critical
Keywords: mozilla0.9.5

Comment 2

17 years ago
Assignee: neeti → darin

Comment 3

17 years ago
nominating 0.9.4, and for nsBranch. this is a serious regression. last time I
checked ual uses multipart mixed to do this, so it's prolly a bug there.
Keywords: mozilla0.9.4, nsbranch

Comment 4

17 years ago
-> moz 0.9.5
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5

Comment 5

17 years ago
it looks like we are downloading everything... i believe the problem doesn't
have anything to do with not processing a redirect properly.  the page uses
dynamic html to hide the "wait page" once the rest of the page is downloaded. 
it does a great deal of sniffing, and i suspect this may be an evangelism bug.

can someone help me confirm this?

Comment 6

17 years ago
-> jst
Assignee: darin → jst

Comment 7

17 years ago
Ok, sorry for blaming the network redirect code, I was sure that was the
problem, but I was wrong, I should've looked closer.

Here's the problem.

The page is loaded with an absolutely positioned div covering the whole screen,
the div shows the "witing" page. The idea on this page is that the page will
show this "waiting" page until the page is fully loaded, when the page is fully
loaded the function 'hideWaitMsg' called. For knowing that the page is fully
loaded the page uses this script at the bottom of the page (note that this
doesn't really show when the page is fully loaded, but I guess this is close
enough for this page):

if((parseInt(navigator.appVersion) == 5) && (navigator.appName== "Netscape")){
} else { 
  document.write("<img src=\"" + "/" +"gif/clear.gif\""+" width=1 height=1"+"

So if appVersion == 5 and appName == "Netscape", which is the case for Netscape
6, the page only does a document.write(""), for all other browsers it writes out
an image tag with onload="hideWaitMsg()", so once the image is loded the
hideWaitMsg() function is called and the "real" page is shown. In Netscape 6x
this method is never called by this page. Why? I don't know.

Simply setting the onload handler on the <body> tag on this page to call the
function hideWaitMsg() would fix this problem on the page for all browsers,
unless calling the onload handler is unreliable in some browsers.

Just to test my theory I changed my user agent to claim that my browser is
version 6 and not 5, and that made this page work in Mozilla/Netscape 6x.

Over to Evangelism.
Assignee: jst → bclary
Component: Networking: HTTP → US English
Product: Browser → Tech Evangelism
QA Contact: tever → zach
Version: other → unspecified

Comment 8

17 years ago
adding topembed. has anyone contacted united?
Keywords: topembed

Comment 9

17 years ago
did anyone notice if they are still using multi-mixed responses? I've been
noticing some funky behavior w/ multi-mixed URLs and I wonder if this is an
incarnation of that.

Comment 10

17 years ago
Judson, why are you adding topembed to pure evangelism bugs?

Comment 11

17 years ago
sorry, I don't know what keeps things on evangelism radar WRT embedding needs.
if there's a better way, please educate me.

also, have we ruled multi-mixed being a possibility?

Comment 12

17 years ago

It seems that jst has the issue analysed pretty well. What needs does embedding
have with regard to this site/issue? afaik, embedding related issues are those
that drive changes in the browser. Any such issues should be filed as bugs
against the product to drive such changes. Evangelism bugs in Bugzilla only
result in contact being made with the site owner to get them to update their
content to support Mozilla and other Gecko based browsers.


Setting up as a pure evangelism bug. 
removing existing keywords: mozilla0.9.4, mozilla0.9.5, nsbranch, topembed
resetting target milestone to blank

For all of you cc'd on this bug, Please remove your cc if you don't want
additional spam related to this bug.
Keywords: mozilla0.9.4, mozilla0.9.5, nsbranch, topembed
Summary: Redirect problem on United Airlines site. → - Redirect problem on United Airlines site.
Target Milestone: mozilla0.9.5 → ---

Comment 13

17 years ago
hey jud,

yeah... it turns out that this page is dynamically changing the DOM...  The 
problem is that it browser sniffs for 'Mozilla 5' and does the *wrong thing* :-(

The page would be much better off if just didn't browser sniff for 'Mozilla 

In fact, jst verified that if the browser sniff failed the page rendered fine 


Comment 14

17 years ago
Great diagnose Johnny!!, 
I am adding a sample testcase (flight results page). I basically followed jst
diag and....

if((parseInt(navigator.appVersion) == 5) && (navigator.appName== "Netscape")){
// inserted this line...
	document.write("<img src=\"" + "/" +"gif/clear.gif\""+" width=1 height=1"+"

 } else { 
document.write("<img src=\"" + "/" +"gif/clear.gif\""+" width=1 height=1"+"

And really works. Actually this is a very cool way to give feedback to users!!!
I loved the approach!. 

Comment 15

17 years ago
Created attachment 50611 [details]
testcase forcing Gecko to have the same behavior.

Comment 16

17 years ago
Ok, Susie Wyshak! got the contact (thanks!) , I spoke with their contact. I am
sending all the Evangelism Rambo Survivor Kit customized to United including one
sample testcase.  Thanks again jst. 

Comment 17

17 years ago
setting 0.9.6 for a checkin to see if this is fixed as per evangelism plan:
Target Milestone: --- → mozilla0.9.6

Comment 18

17 years ago
Just one FYI. navigator.appName="Netscape" with Mozilla and others (based in
Mozilla).. That's why your "other 'Mozilla' browser" is also not working with
this page. 

Guys, do you know why we still say navigator.appName="Netscape" with Mozilla? is
this for compatibility? 
Target Milestone: mozilla0.9.6 → ---

Comment 19

17 years ago
I believe it's compat; yea. there's only so much moving forward one can do :-)

Comment 20

17 years ago
Marcio, since you have contacted the site you should have assigned the bug to
yourself and set a milestone to indicate a timeframe when you think the site
should be retested. Reassigning and setting milestone for followup.
Assignee: bclary → mgalli
Target Milestone: --- → mozilla0.9.6

Comment 21

17 years ago
Thanks Bob. I was actually working with the buscape version ( the one assigned 
to me) and planning to update all the info here with you. 

Comment 22

17 years ago
have they received the packet? this bug makes me use IE.

Comment 23

17 years ago
We contacted,.. we are pushing to help and have the fix done.  Will keep in
touch when fixed.  

Comment 24

17 years ago
FYI, our contact over there was in vacation. We did reply and told me that he
believe the information we provided is sufficient and they may get back in touch
if they need more help on how to fix. I am traking this via my bugscape and will
update here in the proper time. 


Comment 25

17 years ago
Ok. seems like we have some fixes in their side. However still one issue:

Pages like "Fare Finder" and "Flight Status" are using the same JS code to hide
the "LOADING..." panel. Note that Fare Finder is working. The Flight Status is
_not_ working now because they are not calling the JS function in the onload
attribute event (body tag). 


text="#000000" link="#0033CC" vlink="#0066ff" alink="#000000" >

Is missing the onload event (You will see that "Fare Finder" pages includes this
onload handler). 

So I added: 

text="#000000" link="#0033CC" vlink="#0066ff" alink="#000000"

And it's working.... I'll add the sample testcase with this attribute. 


Comment 26

17 years ago
Will send a note again to our contact over there..

Comment 27

17 years ago
I sent one more technical information to our contact over there. Received answer
that they actively working in this at this point. We are getting there. 

Comment 28

17 years ago
*** Bug 110131 has been marked as a duplicate of this bug. ***


17 years ago
Whiteboard: [bugscape 10984]

Comment 29

16 years ago
FYI - this is still broken - win2k, trunk build from today.

Comment 30

16 years ago
*** Bug 116508 has been marked as a duplicate of this bug. ***
Um, should we dupe bug 59083 to this one?  That's a long standing bug on this
same site with a ton of dupes regarding this exact issue, though the original
report is slightly different...

Comment 32

16 years ago
This seems to work now, at least for the flight info and login pages. Can anyone
else confirm that it's fixed?

Comment 33

16 years ago
WFM linux build 2002-01-21/21


16 years ago
Keywords: evang500

Comment 34

16 years ago
Marking fixed. Was fixed in January.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 35

16 years ago
This page appears to be dead.  Cannot verify if fixed.

Comment 36

16 years ago
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.