895045 - All properties for destroyed objects should throw

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

At the moment when we destroy an object, and a developer tries to access a property on the destroyed object after it is destroyed, we return a falsey value, like null or undefined.

It looks like this is not how the web works, try creating a frame, grab a ref to `let win = frame.contentWindow`, destroy the frame, and try to access properties on the `win`, almost all of the properties throw the following error:

[12:14:53.568] Error: Permission denied to access property 'URL'

So many of our APIs are not behaving in a webby manner.

Comment 1

[Ralph Giles (:rillian)]

Re bug 894104:

11:40 < bz> rillian: So...
11:41 < bz> rillian: window teardown is async
11:41 < bz> rillian: so in the testcase the window is not yet torn down when 
            you do frameWin.TextTrackCue
11:41 < bz> rillian: but manually the event loop spins and it gets torn down
11:42 < rillian> ok. is my setTimeout case holding off the teardown then?
11:43 < bz> What does the code for the setTimeout case look like?
11:44 < rillian> http://people.mozilla.org/~rgiles/2013/htmlcue-02.html
11:44 < rillian> it still goes boom even with a 30s timeout
11:44 < bz> Huh
11:45 < bz> I'm not sure, offhand....

Comment 2

[Ralph Giles (:rillian)]

XMLHttpRequest still works, although it loses the origin so relative urls throw NS_ERROR_MALFORMED_URI. See http://people.mozilla.org/~rgiles/2013/htmlcue-04.html for that example.

Comment 3

[Ralph Giles (:rillian)]

Also, Hixie pointed out the spec says the context of an iframe is "discarded" not destroyed, which has different implications. E.g. events don't fire.

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#a-browsing-context-is-discarded

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

As of new APIs I can (In reply to Erik Vold [:erikvold] [:ztatic] from comment #0)
> At the moment when we destroy an object, and a developer tries to access a
> property on the destroyed object after it is destroyed, we return a falsey
> value, like null or undefined.
> 
> It looks like this is not how the web works, try creating a frame, grab a
> ref to `let win = frame.contentWindow`, destroy the frame, and try to access
> properties on the `win`, almost all of the properties throw the following
> error:
> 
> [12:14:53.568] Error: Permission denied to access property 'URL'

Can you give a specific example ??? I'm trying following and everything seems to work just fine:

let frame = document.createElement("iframe")
frame.setAttribute("src", "https://bugzilla.mozilla.org/not-found")
document.body.appendChild(frame)
let doc = frame.contentDocument

frame.parentNode.removeChild(frame)
frame = null

// later
doc.body.innerHTML


> 
> So many of our APIs are not behaving in a webby manner.

In fact I think you're referring is chrome & content interaction which is not a webby. I can't think of any webby API that actually throws exceptions, or allows
underlying components to be GC-ed while references are alive.


Now either way:

1. We should modify existing APIs as that can break existing code & I don't think we can justify that.
2. Webby or not I do agree that early Erros are more helpful than unexpected `null`-s causing errors later in the code. So I'm more than happy to throw descriptive exceptions on attempts to access things that no longer exists, so we could probably incorporate that in the new UI components you guys are working on.

Although I would prefer even better if we could define APIs such that you just won't have a way and need to hold on to things that change under the hood and
can become obsolete. That's why I was pushing towards API where you could just a snapshot of the state of attributes for a specific UI component and not an object that keeps changing and eventually becomes invalid.

We can go through new APIs and see if we can make them work that way, if we can't I'd be +1 on throwing exceptions, but we should make sure that there is a reasonable way of knowing when object is invalidated so users can get rid off references to avoid exceptions. I would not like to make users test if object is still valid on each property access or method call.

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

This bug is a wontfix, as Irakli mentions we could do this for new apis ( the UX work ) but should not break old apis.

Comment 6

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Irakli Gozilalishvili [:irakli] [:gozala] [@gozala] from comment #4)
> As of new APIs I can (In reply to Erik Vold [:erikvold] [:ztatic] from
> comment #0)
> > At the moment when we destroy an object, and a developer tries to access a
> > property on the destroyed object after it is destroyed, we return a falsey
> > value, like null or undefined.
> > 
> > It looks like this is not how the web works, try creating a frame, grab a
> > ref to `let win = frame.contentWindow`, destroy the frame, and try to access
> > properties on the `win`, almost all of the properties throw the following
> > error:
> > 
> > [12:14:53.568] Error: Permission denied to access property 'URL'
> 
> Can you give a specific example ??? I'm trying following and everything
> seems to work just fine:
> 
> let frame = document.createElement("iframe")
> frame.setAttribute("src", "https://bugzilla.mozilla.org/not-found")
> document.body.appendChild(frame)
> let doc = frame.contentDocument
> 
> frame.parentNode.removeChild(frame)
> frame = null
> 
> // later
> doc.body.innerHTML

let f = document.createElement("iframe");
f.setAttribute("src", 'https://google.com');
document.body.appendChild(f);
let w = f.contentWindow;

f.parentNode.removeChild(f)
f = null;

// later
w.URL


> > So many of our APIs are not behaving in a webby manner.

It looks like I made a mistake here, `null` appears to be returned when the frame@src is not cross domain, when it is cross domain I get the error mentioned above.