Bug 13465 – REGRESSION (r20972): Wall Street Journal pages replaced by advertisements

• Component: DOM
• Status: RESOLVED FIXED

[Geoffrey F. Green]

A Javascript which (as far as i can tell) assists in acquiring a series of text advertisements placed in an iframe on Wall Street Journal pages (I've checked article pages and the front page so far) works properly in release versions of Safari, Firefox and Camino but fails in the latest nightly. Instead of inserting the text into an iframe on the page, WebKit replaces the page with the ads. It makes the Wall Street Journal site unusable. I'll attach screenshots from the latest nightly and 419.3 (which renders properly).

[Geoffrey F. Green]

Created attachment 14151 [details]
Screenshot of WSJ home page rendered on latest nightly

[Geoffrey F. Green]

Created attachment 14152 [details]
Screenshot of part of WSJ home page rendered on 419.3

The screenshot shows the advertising block which is near the bottom of the WSJ home page.

[Alexey Proskuryakov]

Confirmed with r21002.

[Alexey Proskuryakov]

I suspect <http://trac.webkit.org/projects/webkit/changeset/20972> (<rdar://problem/4671964> document property on <iframe> elements causes problems for SAP application).

[Darin Adler]

<rdar://problem/5159541>

[Darin Adler]

The problem seems to be that contentDocument and contentWindow are both undefined on new frame elements until they've done enough loading to go from the provisional state to the committed state.

[Darin Adler]

There's code that looks at contentDocument and contentWindow first, then falls back to other properties, including document. It would work fine if contentDocument or contentWindow was defined.

[Darin Adler]

The function is changeIframeSrc and it's in http://online.wsj.com/javascript/commonFunctions.js

[Alexey Proskuryakov]

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

[Geoffrey F. Green]

Fixed in r21368 (change 21367) except that the browser history includes, as a separate entry, the iframe that previously replaced the document. In other words, using the sample error, the proper WSJ page is displayed, but the history list includes both the WSJ page and the title of the iframe page.  Selecting the "iframe entry" from the history list sends you to the iframe.  To clarify, see image of history list below.

[Geoffrey F. Green]

Created attachment 14475 [details]
Screenshot of history list from r21368

[Darin Adler]

(In reply to comment #10)
> Fixed in r21368 (change 21367) except that the browser history includes, as a
> separate entry, the iframe that previously replaced the document. In other
> words, using the sample error, the proper WSJ page is displayed, but the
> history list includes both the WSJ page and the title of the iframe page. 
> Selecting the "iframe entry" from the history list sends you to the iframe.  To
> clarify, see image of history list below.

Lets make a new bug report about this smaller anomaly so we can close this one and put the focus clearly on understanding the cause of the remaining behavior.

[David Kilzer (:ddkilzer)]

(In reply to comment #12)
> Lets make a new bug report about this smaller anomaly so we can close this one
> and put the focus clearly on understanding the cause of the remaining behavior.

Followup is Bug 13686.  Closing this bug per Comment #10.