Add more checks to prevent crashes when accessing name/opener properties

Add more checks to prevent crashes when accessing name/opener properties

Getting/setting these properties can depend on FrameLoaderClient, which
will be null if the frame containing the DOMWindow has already been
detached.

BUG=349956, 352048
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169602

[dcheng, 2014-03-18 23:13:04]

This change appears to bring us in line with Firefox's behavior for
getting/setting a detached DOMWindow's name as well (namely, it should be
ignored and just return an empty string).

[abarth-chromium, 2014-03-19 17:00:36]

lgtm

[commit-bot: I haz the power, 2014-03-19 17:00:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dcheng@chromium.org/203493005/20001

[commit-bot: I haz the power, 2014-03-19 17:03:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 17:03:36]

Try jobs failed on following builders:
  tryserver.blink on win_blink_rel

[dcheng, 2014-03-19 18:06:38]

The CQ bit was checked by dcheng@chromium.org

[commit-bot: I haz the power, 2014-03-19 18:06:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dcheng@chromium.org/203493005/40001

[commit-bot: I haz the power, 2014-03-19 18:33:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 18:33:04]

Try jobs failed on following builders:
  tryserver.blink on linux_blink_rel

[dcheng, 2014-03-19 20:10:17]

So it turns out that:
1) Several layout tests in Blink assume you can set window.name on detached
DOMWindows and that the new name will be visible.
2) IE and Firefox disagree on this case. Firefox returns an empty string for
window.name for a detached DOMWindow; IE returns the last name that was set,
even if set while detached.

I don't really like the current approach, because whether window.name ends up
returning a value is dependent on whether or not the garbage collector has
already run. Any thoughts on how to resolve this conflict?

[abarth-chromium, 2014-03-19 20:11:22]

On 2014/03/19 20:10:17, dcheng wrote:
> So it turns out that:
> 1) Several layout tests in Blink assume you can set window.name on detached
> DOMWindows and that the new name will be visible.
> 2) IE and Firefox disagree on this case. Firefox returns an empty string for
> window.name for a detached DOMWindow; IE returns the last name that was set,
> even if set while detached.
> 
> I don't really like the current approach, because whether window.name ends up
> returning a value is dependent on whether or not the garbage collector has
> already run. Any thoughts on how to resolve this conflict?

Let's match Firefox.  We can update the tests.

[dcheng, 2014-03-20 00:39:17]

Updated the results. I'm unable to verify the results match Firefox, since
Firefox errors out in
http://lxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#334. I
think this bit is called when the internal DOMWindow implementation which
changes on navigation in FF needs to call out to the wrapper DOMWindow.

[dcheng, 2014-03-20 00:39:26]

The CQ bit was checked by dcheng@chromium.org

[commit-bot: I haz the power, 2014-03-20 00:39:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dcheng@chromium.org/203493005/60001

[commit-bot: I haz the power, 2014-03-20 03:47:02]

Change committed as 169602