43958 - when loading my.netscape.com developer.netscape.com they come up blank

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Alek Jeziorek]

-start browser
-enter in the location bar my.netscape.com or developer.netscape.com
-they come up blank
-they should load the pages
linux comm. 2000-06-27-08-M17

Comment 1

[Kathleen :Brade]

I see this on my Macintosh debug build as well (at least for my.netscape.com).

Comment 2

[Doron Rosenberg (IBM)]

note - 43961 is a testcase for developer.netscape.com, in the js engine.

Comment 3

[Blake Ross]

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

Comment 4

[Zach Lipton [:zach]]

I can confirm with Mac OS 9 2000062708. Seems JS related. Should we 
move to JavaScript engine?

Comment 5

[Doron Rosenberg (IBM)]

ok, i accept my bug is a dupe. moving to dom0, moving my testcase for dev.ns.com 
over to here

Comment 6

[Doron Rosenberg (IBM)]

ok, i accept my bug is a dupe. moving to dom0, moving my testcase for dev.ns.com 
over to here

Comment 7

[Doron Rosenberg (IBM)]

Attachment: removing the js fixes this

Comment 8

[Blake Ross]

The contents of the JS page are:

document.write('<a href="http://ads.web.aol.com/link/64000755/html?
badsc=B0kf0FHrevJT4QE7FgKaAuGrAi2nB3bgvu3sP3XtLmWLQZBcuOhBHPfWtyVn1HBdt1iaJMkxDp
T8nqHFLt57cuKTEV1uDf4OvbzQ-EfL_mK7P0fLWYxRbQiOc8zBJ5BaEAXZ-ayIDRn3w$"><img 
src="http://ads.web.aol.com/content/B0/0/dBLtps60oX26difIuGaamMbMKHULd0ytAMyHcK7
14unVmtNj0BUfeh9ZQ6J4EUR6Kt90RwaIDx8KuESIkFGRA-g-tTSFvJi_Ij63tjcM0WQ$/aol" 
border="0" height="60" width="468"></a>\n<BR><A 
HREF="http://ads.web.aol.com/link/64000755/netscape"><B>Click Here!</B></A>');

The JS src url works when entered in the URL bar.  Gagan any idea what's wrong 
here?

Comment 9

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar. 

Comment 10

[Jon Granrose]

all the smoketest results are in.  this is the only bug holding the tree closed.

Comment 11

[Johnny Stenback (:jst)]

This is really a network problem, backing out [e-mail]'s change
that he made yesterday to mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp
v1.198 fixes this problem, should we reassign this to someone else for a fix or
should we back Rusty out?

Comment 12

[Johnny Stenback (:jst)]

v1.198 was backed out, reassigning to [e-mail] for correct fix.

Comment 13

[Johnny Stenback (:jst)]

Changing severity from blocker to normal.

Comment 14

[rusty.lynch]

I'm on it.

Comment 15

[David :Bienvenu]

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

Comment 16

[Blake Ross]

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

Comment 17

[Blake Ross]

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

Comment 18

[Gagan]

this was my mistake. I didn't review your changes correctly. rusty here is what 
the problem is CacheReceivedResponse can return NS_OK even in cases when the 
listener2 is not set. And so the change that should go in is this-

From (line 1992 of nsHTTPChannel.cpp)

CacheReceivedResponse(listener, getter_AddRefs(listener2));         
if (listener2) {

To 

rv = CacheReceivedResponse(listener, getter_AddRefs(listener2));    
if (NS_SUCCEEDED(rv) && listener2) {

Sorry for doing a hasty review! Do you want to check this fix in? 
Thanks!

Comment 19

[Gagan]

likewise for around line 2024

Comment 20

[rusty.lynch]

ok, that explains this morning's bug.  I'll check in the proper fix.

Comment 21

[rusty.lynch]

fix checked in.

Comment 22

[Doron Rosenberg (IBM)]

verified fixed 2000062808 win32 nightly.

Comment 23

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.