Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Boris Zbarsky > What was the outcome of the discussions about possibly having "interface > console" and having all the methods be statics? Another good question which we should probably resolve ASAP. It does indeed change the answer to the related question that starts this thread. Basically developers would really want this, and it was awaiting implementer interest: https://github.com/whatwg/console/issues/3. It looks like according to Paul Irish in https://github.com/whatwg/console/issues/3#issuecomment-172284926 the Chrome Devtools team is up for it, and Firefox used to do this but backed it out. If at least Firefox and Chrome are indeed willing then we should probably spec it that way instead. Ideally Edge and Safari would chime in with their thoughts as well.
Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
On 2/8/16 6:25 PM, Domenic Denicola wrote: So I think the plan of record is: `attribute any console`, with prose describing how the getter returns "the window's console object" which is initially set to a new instance of Console, but the setter can change it to any value. What was the outcome of the discussions about possibly having "interface console" and having all the methods be statics? If we don't want to go that route, then we should do the [Replaceable] thing instead, imo. -Boris
Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
On 2/8/16 9:31 PM, Domenic Denicola wrote: and Firefox used to do this but backed it out. Just for the record, Firefox used to do it back before we had a Web IDL implementation of console at all. At the time it was a giant injected-into-the-page hack, and the particular way it was injected happened to work the way it did. This should not be construed as me arguing against changing the behavior; just a note that it's not as simple as flipping a switch back to something we already had at some point. But I also don't think it would be super-difficult to do... just a bit time-consuming. So the hard part will be finding someone with the time to do it. -Boris
Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
From: Domenic Denicola > So I think the plan of record is: `attribute any console`, with prose > describing > how the getter returns "the window's console object" which is initially set to > a new instance of Console, but the setter can change it to any value. This > means accessor descriptors and enumerable, since that's how IDL works. If > anyone thinks this is bad, let us know. Otherwise the standard will be > updated any day now in that direction. In IRC, Smaug makes me aware of the [Replaceable] IDL attribute, which appears to be what Gecko does. Given `[Replaceable] readonly attribute Console console`, IDL auto-generates a setter that does (essentially) `this.defineOwnProperty("console", { value, writable: true, enumerable: true, configurable: true })`. For most objects this will shadow the prototype's getter, but for global objects like Window it will just overwrite it. So, new plan of record: `[Replaceable] readonly attribute Console console`.
Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
The test harnesses used by the working group which I chair rely on being able to replace window.console. I'd like to see it continue to be mutable. Thanks. On Mon, Feb 8, 2016 at 3:25 PM, Domenic Denicolawrote: > As you may know, we now have a standard for the console object: > http://console.spec.whatwg.org/ > > One of the first issues we encountered while investigating console > behavior is https://github.com/whatwg/console/issues/1, which is that > browsers currently allow setting `window.console` (and presumably > `self.console` in workers) to any value. This is pretty weird, but every > tested browser (Firefox, Chrome, Edge, and Safari) follows it. > > Probably the default course of action here is to just spec this. But we > wanted to check to see if any implementers thought this was weird, and > wanted to experiment with e.g. removing the setter. > > Even if we do go this route, we have another weirdness: > > - Firefox has an accessor descriptor (get/set), Chrome, Safari, and Edge > have a data descriptor (value) > - Firefox, Chrome, and Edge are enumerable; Safari is not enumerable > > I guess Chrome and Safari's data descriptors are not surprising, given > that their bindings infrastructure for Window isn't fully Web > IDL-compatible yet. But Edge is pretty surprising. Travis, do you have any > info on that? > > So I think the plan of record is: `attribute any console`, with prose > describing how the getter returns "the window's console object" which is > initially set to a new instance of Console, but the setter can change it to > any value. This means accessor descriptors and enumerable, since that's how > IDL works. If anyone thinks this is bad, let us know. Otherwise the > standard will be updated any day now in that direction. >