Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console

[Domenic Denicola]

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

[Boris Zbarsky]

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

[Boris Zbarsky]

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

[Domenic Denicola]

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

[Kenneth Russell]

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 Denicola  wrote:

> 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.
>