Closed Bug 58119 Opened 24 years ago Closed 24 years ago

Trying to customize my.aol.com immobilizes app

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: mikepinkerton, Assigned: danm.moz)

References

(
URL
)

Details

(Keywords: crash, top100, Whiteboard: [rtm-]) 

-  go to www.aol.com
- if you get the "your browser sucks" page, hit reload
- click any of the "customize" buttons

Tiny 0x0 window appears, seems to be application modal. Have to force-quit the
app since you can't close it.
this is a show-stopper, IMHO
Keywords: crash, rtm, top100
Clayton is not the right person for this.  I'll reassign to karnaze as a start.

petersen:  is it possible to isolate the html that's causing this?  Thanks.
Assignee: clayton → karnaze
I suspect this is my problem, though I can't reproduce it right now because bug 
56337 is getting in the way on my machine.

Reassigning to danm.
Assignee: karnaze → danm
marking [rtm need info] since you're working on it.  Would it help if someone
from my team could provide you a machine to build on?
Whiteboard: [rtm need info]
What causes anyone to get the browser sucks message?  How often will that really
happen to anyone?  If the answer isn't "all the time" then maybe it's time to
rtm- this.
the answer isn't "all the time" but it seems to be "most of the time".
Obviously, I got in a couple of times in order to be able to file the bug, but
getting there again has been difficult.
This works sometimes? Here's the relevant source for the first page:

<HTML> 
<HEAD> 
<SCRIPT> 
var ua=navigator.userAgent; 
var isGood=false; 
var isWin=false; 
//redirect badbrowsers 
if (ua.indexOf('MSIE 4.')!=-1||ua.indexOf('MSIE 5.')!=-1||(navig
ator.appName=="Netscape"&&parseInt(navigator.appVersion)>=4)) 
isGood=true; 
if (ua.indexOf('Win')!=-1) isWin=true; 
if (isWin&&isGood) ;//no redirect 
else if (!isWin&&ua.indexOf('MSIE 5.')!=-1) ;//no redirect 
else location.href="/shared/badbrowser.psp"; 
</SCRIPT>

If you ever get through with Mozilla, which identifies itself as "Mozilla/5.0", 
then it seems like you must be uncovering some timing bug where quickly changing 
location.href doesn't take.

Presumably some day my.aol.com will change that script, and then this will be a 
real issue. In the meantime, you can alter Mozilla's User Agent, forcing it to 
identify itself as Navigator 5 or IE 5 or something, to get around this.

When I tried that I got the hang from an other of mine, bug 55460/56337, which 
has been kicking my butt for several days. That's where I'm spending all the time 
I can right now. Love to get those fixed. Don't have a grip on the problem yet. 
Thought it was happening only on some machines, and only on the trunk.

rtm-/future  How did this bug even get on our rtm radar?
Whiteboard: [rtm need info] → [rtm-]
Target Milestone: --- → Future
  Looks like still more fallout from the 1 Oct nsThread checkin. With that 
problem unfixed on my machine, I can't even get as far as seeing a "customize" 
button: Mozilla wedges when I try to sign in. With that problem fixed, I get to 
sign in, and I get a fine, nonmodal "customize" window. Woo hoo.
  PS AOL seems to have removed "your browser sucks" for Mozilla, so no user agent 
mods are necessary to test.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla0.8
Marking verified in the March 01 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.