177564 - My Washington Post - document.write during page load trashes existing content

Status: RESOLVED FIXED

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

Description

[Bob Clary [:bc] (inactive)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021024
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021024

This bug was spawned from an internal evangelism bug:
http://bugscape.nscp.aoltw.net/show_bug.cgi?id=16102

This page will open a popup and redirect the main window to 
http://www.washingtonpost.com/ac2/wp-dyn?node=personalization/mywp/display&destination=startPage&nextstep=refresh

The page will load until a document write is reached when the current contents
of the page are lost and replaced by the contents which was just written out.
This document write occurs before the end of the page.

Note that if you visit 
http://www.washingtonpost.com/ac2/wp-dyn?node=personalization/mywp/display&destination=startPage

directly, then you do not see the problem. It appears solely due to the refresh
that is caused by the popup window when invoked via the original url
http://mywashingtonpost.com

Essentially the verdict in bugscape was:

------- Additional Comment #19 From Radha Kulkarni 2002-08-27 16:49 -------

Looking thro' the debugger. The full page is loaded and then,

document.writeln("<table width="308" cellpadding="0" cellspacing="0" border="0"
bgcolor="#ffffff"><tr><td width="99" height="5" colspan="2"><SPACER TYPE="BLOCK"
WIDTH="99" HEIGHT="5"></td></tr> <tr> <td valign="top" align="left"
colspan="2"><table width="300" </table>");  is done, followed by ...

document.write("<SCRIPT language='JavaScript1.1'
SRC='http://ad.doubleclick.net/adj/wpni.mywashpost/home;kw=mywashpost;pos=ad11;sz=120x600;tile=1;;ord="
+ ord + "'></SCRIPT>"); 

There is no document.close(), so the throbber keeps rotating. Since a
document.write() is done on the main document, session history creates a wyciwyg
entry for it and the original document is replaced by this "markets" stuff. I
suggest that they create a iframe  and do the document.write() in to the iframe
instead of the main document.



Reproducible: Always

Steps to Reproduce:
1. Turn off Popup blocking
2. Load http://mywashingtonpost.com


Actual Results:  
document.write of Ad content replaces page

Expected Results:  
inserted the Ad content into the page

Yes, I have contacted them and offered work arounds, with no luck. If this is a
bug in the browser, then can we fix it for 1.3?

Comment 1

[Bob Clary [:bc] (inactive)]

carrying forward some cc's from bugscape.

Comment 2

[Susie Wyshak]

I am marking this topembed. cc'ing Evelyn.

Comment 3

[Chris Nalls]

Kevin - can you take a look at this and let us know if this is a product bug
that we can address? Thanks - topembed triage team.

Comment 4

[Kevin McCluskey (gone)]

-> Karnaze. Chris can you take a look at this?

Comment 5

[karnaze (gone)]

Can we get a reduced tests case?

Comment 6

[Bob Clary [:bc] (inactive)]

A similar though not completely identical issue is in bug 178601. In test case 2
in that bug Mozilla 1.0.2 will exhibit similar behavior although Mozilla 1.2b
will not. That differs slightly from this bug since both Mozilla 1.0.2 and 1.2b
have the problem for mywashingtonpost.com.

See http://bugzilla.mozilla.org/attachment.cgi?id=105296&action=view

Comment 7

[Doron Rosenberg (IBM)]

shouldn't they use a window.open before the window.write and then window.close()?

Comment 8

[Bob Clary [:bc] (inactive)]

Attachment: test script

Comment 9

[Bob Clary [:bc] (inactive)]

Attachment: test case (not relevant to this bug)

this test case is the same as the one in bug 178601 except it has a
document.close after the document.write.

Comment 10

[Bob Clary [:bc] (inactive)]

Will someone please look at this?

Comment 11

[karnaze (gone)]

The test case works for me on my 11/19/2 win2k debug trunk build (there are
three lines of text). I had a 10/26/2 trunk build and the test case works on
that also, which is before the m1.2 branch, I think. Is the problem that it
doesn't work on the m1.2 branch? If so, can someone in qa find out what build it
stopped working on. That will be easier than trying to fix a bug a 2nd time,
especially if someone else fixed it the first time.

Comment 12

[karnaze (gone)]

Forget that last sentence. I should have said that we need to find out what
build broke the test case.

Comment 13

[Bob Clary [:bc] (inactive)]

Sorry, I should have made it clearer that the test case came from bug 178601
(with the document close added) and that it worked in 1.2 and the trunk but not
on 1.0.2.   It was meant to address the comment that document.close would fix
the problem.

I still see the problem behavior at mywashingtonpost.com however in trunk builds
from 2002 11 14/win2k.

Comment 14

[karnaze (gone)]

I'm starting to think that the current url will not work on any of our older
builds. I don't have very many old builds, but it is broken on 10/26/2. The next
earlier one I have is 12/13/1 (10 months prior) and it is broken on that one
also. Radha's comments mentioned in the summary seem relevant. I opened the url
in Viewer and got the following errors. When I dumped content, there was very
little. 

I don't think this a layout bug, since there is no content, but don't know who
to give it to.


CSS Error (http://www.washingtonpost.com/ac2/wp-dyn?node=personalization/mywp/di
splay&destination=startPage&nextstep=refresh :1.50): Unknown property 'include-s
ource'.  Declaration dropped.
WEBSHELL+ = 2
JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 0x8
0004005 (NS_ERROR_FAILURE) [nsIDOMHTMLDocument.cookie]"  nsresult: "0x80004005 (
NS_ERROR_FAILURE)"  location: "JS frame :: http://www.washingtonpost.com/wp-srv/
mywp/html/popup.js :: getCookie :: line 12"  data: no]

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 0x8
0004005 (NS_ERROR_FAILURE) [nsIDOMHTMLDocument.cookie]"  nsresult: "0x80004005 (
NS_ERROR_FAILURE)"  location: "JS frame :: http://www.washingtonpost.com/wp-srv/
mywp/html/popup.js :: getCookie :: line 12"  data: no]

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 0x8
0004005 (NS_ERROR_FAILURE) [nsIDOMHTMLDocument.cookie]"  nsresult: "0x80004005 (
NS_ERROR_FAILURE)"  location: "JS frame :: http://stats.surfaid.ihost.com/crc/sa
cdcwp.js :: s_l :: line 5"  data: no]

WARNING: empty damage rect: update caller to avoid fcn call overhead, file s:/mo
zilla/layout/html/base/src/nsFrame.cpp, line 2531
JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 0x8
0004005 (NS_ERROR_FAILURE) [nsIDOMHTMLDocument.cookie]"  nsresult: "0x80004005 (
NS_ERROR_FAILURE)"  location: "JS frame :: http://stats.surfaid.ihost.com/crc/sa
cdcwp.js :: s_l :: line 5"  data: no]

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 0x8
0004005 (NS_ERROR_FAILURE) [nsIDOMHTMLDocument.cookie]"  nsresult: "0x80004005 (
NS_ERROR_FAILURE)"  location: "JS frame :: http://www.washingtonpost.com/wp-srv/
mywp/html/popup.js :: getCookie :: line 12"  data: no]

JavaScript error:
http://www.washingtonpost.com/ac2/wp-dyn?node=personalization/mywp/display&desti
nation=startPage&nextstep=refresh line 4: bMywpStaticPage is not defined

JavaScript error:
http://www.washingtonpost.com/ac2/wp-dyn?node=personalization/mywp/display&desti
nation=startPage&nextstep=refresh line 0: placeSiteMetrix is not defined

###!!! ASSERTION: aNode is neither an nsIContent nor an nsIDocument!: 'Error', f
ile s:/mozilla/content/base/src/nsContentUtils.cpp, line 585
Break: at file s:/mozilla/content/base/src/nsContentUtils.cpp, line 585

nsDebug::Assertion(const char * 0x01f08e64, const char * 0x0035f838, const char
* 0x01f08e34, int 585) line 280 + 13 bytes
nsDebug::Error(const char * 0x01f08e64, const char * 0x01f08e34, int 585) line
463 + 22 bytes
nsContentUtils::CanCallerAccess(nsIDOMNode * 0x00000000) line 585 + 21 bytes
nsRange::SetStartAfter(nsRange * const 0x0368af28, nsIDOMNode * 0x00000000) line
1079 + 9 bytes
XPTC_InvokeByIndex(nsISupports * 0x0368af28, unsigned int 11, unsigned int 1,
nsXPTCVariant * 0x0012eb38) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2016 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x014f4e38, JSObject * 0x0161d0b8, unsigned int 1,
long * 0x03157010, long * 0x0012ede8) line 1283 + 14 bytes
js_Invoke(JSContext * 0x014f4e38, unsigned int 1, unsigned int 0) line 839 + 23
bytes
js_Interpret(JSContext * 0x014f4e38, long * 0x0012f790) line 2803 + 15 bytes
js_Execute(JSContext * 0x014f4e38, JSObject * 0x01143b18, JSScript * 0x0152c3d0,
JSStackFrame * 0x00000000, unsigned int 0, long * 0x0012f790) line 1020 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x014f4e38, JSObject * 0x01143b18,
JSPrincipals * 0x03681668, const unsigned short * 0x01636ec8, unsigned int 901,
const char * 0x037059f0, unsigned int 0, long * 0x0012f790) line 3382 + 25 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x014f4dc0, const nsAString &
{...}, void * 0x01143b18, nsIPrincipal * 0x03681664, const char * 0x037059f0,
unsigned int 0, const char * 0x00531418, nsAString & {...}, int * 0x0012f7f4)
line 701 + 85 bytes
nsScriptLoader::EvaluateScript(nsScriptLoadRequest * 0x03718010, const
nsAFlatString & {...}) line 586
nsScriptLoader::ProcessRequest(nsScriptLoadRequest * 0x03718010) line 493 + 22 bytes
nsScriptLoader::ProcessPendingReqests() line 600
nsScriptLoader::OnStreamComplete(nsScriptLoader * const 0x014bad4c,
nsIStreamLoader * 0x036cfc68, nsISupports * 0x036aaf58, unsigned int 2152398850,
unsigned int 0, const char * 0x02eea278) line 658
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x036cfc6c, nsIRequest *
0x03663ae8, nsISupports * 0x036aaf58, unsigned int 2152398850) line 144
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x03663aec, nsIRequest *
0x0364e3c4, nsISupports * 0x036aaf58, unsigned int 2152398850) line 2980
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x035e9de4) line 116
PL_HandleEvent(PLEvent * 0x035e9de4) line 644 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010e6fb8) line 574 + 9 bytes
_md_TimerProc(HWND__ * 0x002f0266, unsigned int 275, unsigned int 0, unsigned
long 17067351) line 930 + 9 bytes
USER32! 77e12e98()
USER32! 77e13158()
USER32! 77e15824()
main(int 1, char * * 0x006481b8) line 155 + 11 bytes
mainCRTStartup() line 338 + 17 bytes

Comment 15

[Kevin McCluskey (gone)]

based on comment #14 this doesn't sound like a layout issue since there aren't
any frames created. Perhaps it is related to the DOM?

Passing over to the DOM guys to take a look.

Comment 16

[Johnny Stenback (:jst)]

After scratching my head over this for some time I finally figured out what is
going on here, it's not nearly as complicated as it seemed, and it turns out
that there's no problem with Mozilla here, Mozilla is doing exactly what the
site tells it to do.

Site in question works as follows:

The page http://mywashingtonpost.com (or whatever it's redirected to) contains a
hidden iframe that loads
http://www.washingtonpost.com/wp-dyn/personalization/mywp/display. In that
hidden iframe, all the content that'll eventually appear in the window is
loaded, and once it's all loaded, the following (inline) script is executed:

  if (document.all)
  {
    if (parent.document.staticForm.staticInput.value==1)
    {
      parent.document.all.staticSpan.innerHTML = document.body.innerHTML
    }
  }
  else if (document.layers)
  {
    //do nothing
  }
  else if (parseInt(navigator.appVersion)>=5)
  {
    if (parent.document.staticForm.staticInput.value=="1")
    {
      var l = parent.document.getElementById('staticSpan');
      var r = parent.document.createRange();
      r.setStartAfter(l);
      var docFrag = r.createContextualFragment(document.body.innerHTML);
      while (l.hasChildNodes())
        l.removeChild(l.firstChild);

      l.appendChild(docFrag);
    }
  }
  else
  { ... }

And there you see that they serialize the content of document.body and create a
document fragment from that, then that document fragment is inserted into the
parent document (mywashingtonpost.com).

This is where the problem comes in, the content they're inserting into the
toplevel document contains script elements (inline and external ones), so once
those are insterted into the document Mozilla will start executing those
scripts, and those scripts do document.write() which now will do an implicit
document.open() to reset the document, and then do the write.

IOW, this is an evangelism issue, if the site executed the same code in Mozilla
that it does for IE, e.g.:

  parent.document.all.staticSpan.innerHTML = document.body.innerHTML

then the site would work as expected in Mozilla too, since we explicitly do
*not* execute scripts when setting innnerHTML for compatibility with IE.

Over to evangelism.

Comment 17

[chris hofmann]

who should own now?   susie? bob?

Comment 18

[Bob Clary [:bc] (inactive)]

fixed.