484857 - document.location incorrect in document.write-generated frame content

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[Mathieu Fenniak]

Attachment: test case

When document content is written with document.write, the content's document.location appears to be the location of the document that the Javascript is executing on, overwriting the expected document location.

Reproduce with attached testcase:

1. Open test1.html.  On the left side of the window is "test1.html", and the right side frame is about:blank.  The left side frame contains document.write(document.location), which outputs test1.html's path.

2. Click "Click".  This causes "dir/test2.html" to be loaded in the right side frame; test2's javascript causes the left-frame to be reloaded.

3. Notice that the path visible in the left frame has changed to "dir/test2.html", and the left frame's image is now a broken img.  EXPECTED: the left frame's location to remain the same, and the image to continue to work.

The expected behavior occurs on IE7, Safari 4, Firefox 3.0.6.

This issue affects FF 3.0.7 (1.9.0.7), as well as the current trunk.  1.9.0-branch regression range is 2009-01-27-05 - 2009-01-28-06, which suggests the patch for bug 445004 is the cause of the issue.

Comment 1

[Mathieu Fenniak]

Attachment: expected behavior after "Click", IE7

Comment 2

[Mathieu Fenniak]

Attachment: current behavior after "Click", FF 3.0.7

Comment 3

[Mathieu Fenniak]

Requesting blocking1.9.0.8.  Issue is currently causing serious grief for customers of our web application, no workaround known.

Comment 4

[Mathieu Fenniak]

Bug 481647 may be the same issue.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.  So this does not match what my testing of IE7 showed.  See https://bugzilla.mozilla.org/show_bug.cgi?id=445004#c24 and the tests I checked in for bug 445004, which I used to test IE.  I wonder what's different about this testcase...

As in, I had implemented exactly the behavior IE7 had, from what I could tell in my testing.

Comment 6

[Nochum Sossonko [:Natch]]

Is this not fixed by bug 482659? (downloading the nightly now...)

Comment 7

[Mathieu Fenniak]

Just checked, broken in 2009-03-23-05-mozilla1.9.0.

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK, the key difference is the "GUI" thing.  Testcase coming up, hopefully.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Oh, and bug 482659 is not really relevant here.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So just to summarize, here's the skinny.  The testcase as written works in IE and Safari and is broken in Opera.  It used to work in Gecko prior to the fix for bug 445004, and now it fails.

If I change the testcase so that instead of doing:

  GUI = {}
  GUI.renderDisplay = function () ....

it does:

  function renderDisplay() ..

and change the test2.html file to call |window.parent.renderDisplay()|, then the testcase fails in Opera, current Gecko, and IE.  It still passes in Safari, and used to pass in old Gecko.

That is, for the case when the function is called via the window object we used to have behavior different from IE and Opera, and identical to Safari.  Bug 445004 fixed that so that now our behavior for that testcase is identical to IE and Opera, with Safari the lone holdout.  But it fixed it while keeping our behavior consistent: it doesn't matter what object the function being called is a property of.  Apparently in IE it does.  So on the testcase in this bug, while we still match Opera, we no longer match IE, while Safari does.

I have no idea how IE is differentiating between these two cases.  Does anyone?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Obvious options here are:

1)  Do nothing; claim that IE's behavior simply makes no sense and stick to being
    compatible with IE in the simple case and self-consistent in other cases.
2)  Try to reverse-engineer what IE is really doing and reproduce it.

Quite honestly, my gut feeling is to stick with (1) given the small number of reports we've seen on this issue so far in the 4 months since this was initially checked in on both trunk and 1.9.1 (this is the only report complaining about this issue thus far).  To reproduce this, one has to be calling document.write from on document C by calling a function in document B that calls a function in document A (possibly equal to document C) that is a property of some object in document A, and then expect the base URI of the resulting document to be that of A, not B (which means in particular that they must have different base URIs).  At the same time one must not call any global functions in document A that do document.write, since those have different behavior in IE...

Comment 12

[Daniel Veditz [:dveditz]]

1.9.0.8 is past code freeze. If we had an obvious check-for-null type small safe fix we might be able to squeeze in a regression fix, but this promises to be messy (still arguing over correct behavior) and 1.9.0.9 is the earliest we could realistically consider it.

Comment 13

[Mathieu Fenniak]

I completely agree that option 2 is not correct.  It seems to me that the difference in behavior in IE between a window-level function and an object-level function is an IE bug that FF shouldn't reproduce.

I've put together a small spreadsheet that illustrates the different behaviors between browsers, including FF306 and FF307 (http://spreadsheets.google.com/pub?key=pmWwJgWkZU39XL0NdktblP).  Excluding IE for its inconsistency, both Safari and Opera's behavior makes sense from a given point-of-view, so I can't convincingly argue for either specific behavior.

As a workaround, I've addressed the issue in the application I'm working on by including a <base href="..."> tag in the frame content written with document.write.  Since this type of workaround is required for other browsers anyways, any resolution of this bug report seems reasonable.

Comment 14

[Mathieu Fenniak]

Sorry, that URL should've been http://spreadsheets.google.com/pub?key=pmWwJgWkZU39XL0NdktblPg

Comment 15

[Boris Zbarsky [:bzbarsky]]

I think given that, I'd prefer to wontfix this....