User Agent: Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131025151332 Steps to reproduce: goto http://mynichecomputing.org/outline/ and try Remove Current (also does not work in version 24;. THIS IS AN OLD, POPULAR LONG-USED PROGRAM) Actual results: Nothing , except button disapears Expected results: Highlighted item in outline should be removed

SAME PROBLEM EXISTS ON WINDOWS 8 AND VERSION 24 OF FF

The relevant button is: <input type = "button" value = "Remove Current" onclick = "remove()" class = "submit" /> So this used to call the global remove() function, until http://dom.spec.whatwg.org/#dom-childnode-remove got implemented. Now it does the equivalent of this.remove() on the input, which just removes the button from the DOM. We implemented support for that spec in Firefox 23, so presumably that's when it broke. This is also broken, for the same reason, in recent Chrome and Safari. Reporter, if this is your page you can change that onclick attribute to: onclick="window.remove()" and it will work again. Anne, we may need to make ChildNode.remove @@unscopeable once such a thing exists...

I understand what I needed to do and I made the fix, but this re-interpretation of what a function is called on via onclick is way-'different', and it seems needless and also seems unacceptable. Are monkeys at the keyboards writing "standards"?? (In reply to Boris Zbarsky [:bz] from comment #2) > The relevant button is: > > <input type = "button" value = "Remove Current" onclick = "remove()" class > = "submit" /> > > So this used to call the global remove() function, until > http://dom.spec.whatwg.org/#dom-childnode-remove got implemented. Now it > does the equivalent of this.remove() on the input, which just removes the > button from the DOM. > > We implemented support for that spec in Firefox 23, so presumably that's > when it broke. > > This is also broken, for the same reason, in recent Chrome and Safari. > > Reporter, if this is your page you can change that onclick attribute to: > > onclick="window.remove()" > > and it will work again. > > Anne, we may need to make ChildNode.remove @@unscopeable once such a thing > exists...

Yes.

> but this re-interpretation of what a function is called on via onclick is way-'different' The problem is that the scope chain for onclick handlers like that includes the element the handler is on. So by default, any method added to the element will become visible in that handler. Yes, this is a significant pitfall; it means either not adding any functionality to elements ever or writing onclick handlers carefully (always prefixing bareword function calls with "window."; that's been the recommended best practice for years) or getting the JavaScript language specification changed to allow adding things without having them show up in the scope. We're working on this last, but it involves changing the definition of JavaScript and then implementing the new functionality, which is unfortunately not something that happens overnight.

(In reply to lorlarz from comment #4) > Are monkeys at the keyboards writing "standards"?? All the monkeys are much too busy filing bugs.

Fixed by bug 1104955 making remove() unscopable.