Closed Bug 100247 Opened 23 years ago Closed 22 years ago

ual.com - Redirect problem on United Airlines site.

Categories

(Tech Evangelism Graveyard :: English US, defect, P1)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jst, Assigned: mgalli)

References

(
URL
)

Details

(Whiteboard: [bugscape 10984])

Attachments

(1 file)

testcase forcing Gecko to have the same behavior.
36.48 KB, text/html
Details 
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.
Upping the severity to critical given that this is a major site
Severity: normal → critical
Keywords: mozilla0.9.5
darin
Assignee: neeti → darin
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
-> moz 0.9.5
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
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?
-> jst
Assignee: darin → jst
Status: ASSIGNED → NEW
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")){
  document.write("");
} else { 
  document.write("<img src=\"" + "/" +"gif/clear.gif\""+" width=1 height=1"+"
onLoad=\"hideWaitMsg()\">");
}

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
adding topembed. has anyone contacted united?
Keywords: topembed
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.
Judson, why are you adding topembed to pure evangelism bugs?
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?
Judson,

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.

Bob

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. → ual.com - Redirect problem on United Airlines site.
Target Milestone: mozilla0.9.5 → ---
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 
5.0'.

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


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"+"
onLoad=\"hideWaitMsg()\">");

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

And really works. Actually this is a very cool way to give feedback to users!!!
I loved the approach!. 
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. 
setting 0.9.6 for a checkin to see if this is fixed as per evangelism plan: 
mozilla-evangelism.bclary.com
Target Milestone: --- → mozilla0.9.6
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 → ---
I believe it's compat; yea. there's only so much moving forward one can do :-)
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
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.
Status: NEW → ASSIGNED
have they received the packet? this bug makes me use IE.
We contacted,.. we are pushing to help and have the fix done.  Will keep in
touch when fixed.  

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. 


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

Note: 

<body bgcolor="#FFFFFF" TOPMARGIN=0 LEFTMARGIN=0 MARGINWIDTH=0 MARGINHEIGHT="0"
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: 

<body bgcolor="#FFFFFF" TOPMARGIN=0 LEFTMARGIN=0 MARGINWIDTH=0 MARGINHEIGHT="0"
text="#000000" link="#0033CC" vlink="#0066ff" alink="#000000"
onLoad="hideWaitMsg()">

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



Will send a note again to our contact over there..

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. 
*** Bug 110131 has been marked as a duplicate of this bug. ***
Whiteboard: [bugscape 10984]
FYI - this is still broken - win2k, trunk build from today.
*** 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...
This seems to work now, at least for the flight info and login pages. Can anyone
else confirm that it's fixed?
WFM linux build 2002-01-21/21
Keywords: evang500
Marking fixed. Was fixed in January.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
This page appears to be dead.  Cannot verify if fixed.
Verifying
2002040303/WinXP
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: