Missing methods: dir, dirxml, markTimeline, timeStamp, timeline, timelineEnd, exception

[domenic]

These seem to exist in a few different browsers.

[terinjokes]

What benefit do dir and dirxml have over format specifiers?

@paulirish had mentioned at one point that markTimeline, timeStamp, timeline, and timelineEnd (and simpler) were going to be removed from Chrome, and with the uncertainty I didn't include them. This decision seems to have been reversed, as they still exist.

I haven't previously considered exception.

[domenic]

I doubt they have any benefit, but they're implemented, so we gotta spec 'em.

exception is not in Chrome but is in Edge and Firefox.

[paulirish]

timeline and timelineEnd are deprecated and nonfunctional in Chrome. they were unique to us. i would exclude from the spec.

markTimeline is deprecated, but functional. it's equivalent to timeStamp. this was also unique to chrome.

timestamp we do use, and Edge does as well.

[domenic]

Hmm Firefox supports timeline and timelineEnd. I wonder if we'll need to spec them as no-ops to avoid crashy pages.

markTimeline is also in Firefox.

Found http://mxr.mozilla.org/mozilla-central/source/dom/webidl/Console.webidl ... it looks like markTimeline, timeline, and timelineEnd are specifically no-ops there.

[paulirish]

dir and dirxml are useful when logging DOM/SVG/XML elements. dir will log the object representation (like a JS object). dirxml will log a tree like what you see in the DOM/Elements panel.

[terinjokes]

@paulirish and we have formatters in the spec for both behaviors already.

3.2. Formatting specifiers that require a complex UI

Specifier	Function	Type Conversion
%o	Displays as expandable DOM element	n/a
%O	Displays as expandable JS Object	n/a

[domenic]

Sure but console.dir(o) is nicer than console.log("%O", o). Anyways it doesn't really matter; browsers support it so it needs to be specced.

[paulirish]

@paulirish and we have formatters in the spec for both behaviors already.

@terinjokes our implementation right now is:

EDIT: moved this discussion of %o and %O into #36

[terinjokes]

since everybody really just wants the dir(elem) behavior when they log an element.

Is this simply because they don't know that %O exists? There are many cases where I want the %o (aka dirxml) behavior, and other cases where I want %o (aka dir).

[terinjokes]

@domenic To clarify, markTimeline, timeline and timelineEnd should be in this spec as noops? Is it feasible to follow the HTML and JS specifications and have them in an annex?

[domenic]

I don't really think there's any point in having an annex. HTML's separation is largely about what authors should use vs. what implementers should implement, and ES's separation is just dumb. (It's in theory "non-browser implementations don't have to do this," except they actually do, because code expects it to exist.)

[MylesBorins]

If people are open to helping me through the process I'd be interested in taking on console.dir( ).

Are there any CONTRIBUTING docs?

[domenic]

Hey @thealphanerd, sorry for the delay! With the holidays I imagine all our time is a bit touch-and-go, but in general I'd be happy to help you through the process, and I'm sure @terinjokes and @robertkowalski (the spec editors) would be as well.

There aren't any CONTRIBUTING.md docs at the moment, but https://github.com/whatwg/console#building-the-spec should get you started with the basics

[domfarolino]

Reviving this thread, though if it gets much longer it might be worth breaking it up a bit.

Regarding dir and dirxml:

• We can probably just say for dir what we said for %O in the format specifier table
• We can't say for dirxml what we said for %o however, because %o (most useful) may not always mean DOM tree formatting when dealing with an element as @paulirish said in %o specifier uses type-specific formatter #36. We can probably say dirxml tries for DOM tree formatting where possible, and %o formatting when not.

Through some testing, I also found that that in Chrome, Firefox, and Safari, dir only takes in/logs one argument whereas dirxml takes in/logs a sequence. In Safari, the parsing of this sequence is odd. If the first parameter passed into dirxml is a string (not via conversion) it will log something a custom "grouping" whose label is this string, and whose entries are the remaining elements in the sequence. In the case where the first item is not a string, the "grouping" has no title, and all sequence elements appear in it. Personally I think this should be changed to just log all elements together instead of creating a sort of titled "grouping", unless I'm missing something. Thoughts @JosephPecoraro?

Regarding timeline and timelineEnd:

They both take in a string for a label.

• Chrome has the only functioning implementation of both, though they are deprecated (any plan for removal @paulirish ?).
• FF has the only noop implementation (for compatibility I presume).
• Safari has no support.
• Not sure about edge.

Seems like we should spec as noop. @domenic Does this require any special care in IDL, or do we just put it in with a definition similar to "this is non operational and exists for compatibility reasons"?

[paulirish]

In Chrome timeline/timelineEnd just add a deprecated notice and otherwise fallback to console.time() behavior. Removing them means console.timeline is not a function exceptions for people, however admittedly very few apps would be affected.

It's unlikely code using this is deployed, so I don't think its a big priority to spec. (Same with edge's console.takeHeapSnapshot)

[domenic]

Seems like we should spec as noop. @domenic Does this require any special care in IDL, or do we just put it in with a definition similar to "this is non operational and exists for compatibility reasons"?

The latter works great.

Edge does not have timeline/timelineEnd. (It does have timeStamp.) Hmm. If Chrome is willing to remove we could not spec it... Maybe filing bugs is the way to go. Not sure.

[paulirish]

I think we're willing to remove. I'll verify.

[domfarolino]

Motivation for not wanting to spec it makes sense but I feel like even if it exists in one place, we have to (at least noop) so that implementations don't follow the spec yet still make some sites exception-prone. I'll whip something up for dir and dirxml, and wait for @paulirish to get back regarding timeline/timelineEnd (thanks!).

I'll break timeStamp, markTimeline and exception out into another issue hopefully tomorrow. Been pretty sick the past week so things are moving slow :(

[domenic]

Well if it only exists in two browsers with one spewing a deprecation warning it seems possible it's not required for web compat and thus the best path forward might be removal.

[domfarolino]

Just going to keep timeStamp, markTimeline, and exception in this issue because they shouldn't take too much to resolve.

Seems that we can definitely spec timeStamp as it is pretty widely supported (Chrome + Canary, Firefox, Safari + Tech Preview, and Edge as indicated by Domenic and Paul). I'm thinking markTimeline be specced as noop as it only appears functional in Chrome, noop in Firefox, not at all in Safari, (edge?).

exception only appears in Firefox and Edge, and at least in Firefox it is nothing but an alias for error.

Argument for dropping it: Provides no functional benefit over the already-existing error.
Argument for keeping it ( + adding to spec): Dropping it may cause some (probably few) sites to have issues, and it is implemented in two browsers as it is.

Thoughts?

[domenic]

markTimeline does not appear in Edge. I wonder if it should be a no-op or if it should be allowed to do something useful so that Chrome doesn't have to change.

Exception... it looks like Firefox added it a few years ago based on an older spec: https://bugzilla.mozilla.org/show_bug.cgi?id=922214.

I guess in both of these cases where it doesn't exist in 2/4 browsers I'd err toward speccing them. They're pretty harmless and browsers are unlikely to want the potential compat fallout, however small, of removing them.

[JosephPecoraro]

WebKit removed console.markTimeline in favor of console.timeStamp nearly 4 years ago (here). I do not recall any issues since. I don't think it would be worth adding a no-op to a spec.

This is also the first time I've heard of console.exception. Since its not available in all browsers and it is equivalent to an API that is working in all browsers, console.error, I don't see a lot of value to speccing it if we could instead strive to phase it out somehow.

[paulirish]

Chrome is comfortable with removing timeline & timelineEnd (and breaking anyone still using it).

[domenic]

Nice. We can write web-platform-tests asserting the nonexistence of these methods. (Typically such tests are suffixed with -historical.html; you can find a number of examples.)

[domfarolino]

In an effort to close this very soon:

I'll add a PR to spec timeStamp.

markTimeline no longer exists in Firefox (part of https://bugzilla.mozilla.org/show_bug.cgi?id=1351795), the only browser other than Chrome to implement it (even though it was no-op I believe) in the past 4 years. It is also deprecated in Chrome in favor of timeStamp, so I vote on leaving it out of the spec and adding a historical test for nonexistence.

Do we still want to spec exception @domenic ? Personally I'm in favor of excluding it and phasing it out, though I'm not totally sure if that's the best option.

[domenic]

So console.exception() is in Edge and Firefox but not Chrome, Safari, or Node.js. Hmm. It'd be ideal to get sign-off from Edge and Firefox on removing. @TheLarkInn do you know if Edge is up for removing it? Not sure who to ask from Firefox, so... @bzbarsky?

In general I lean toward adding things to console, but so far people in this thread have been pretty open to removing them, so I guess it's worth asking.

[domfarolino]

Pinging @bgrins for Firefox and @xirzec for Edge as well

[TheLarkInn]

I'd just need to examine current usage and our existing behavior for that method and I'll jump back in thread and let you know.

…

On Fri, Feb 16, 2018, 11:03 AM Dominic Farolino ***@***.***> wrote: Pinging @bgrins <https://github.com/bgrins> for Firefox and @xirzec <https://github.com/xirzec> for Edge as well — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADQBMJWDr1lGV8kOeu8vNHH28qCB3BXyks5tVdDbgaJpZM4HB-RK> .

[bzbarsky]

The history for console.exception seems to be https://bugzilla.mozilla.org/show_bug.cgi?id=922214 where it came from a now-no-longer existing spec draft at https://github.com/DeveloperToolsWG/console-object

Looking at the blame there, it was added by @bkardell in DeveloperToolsWG/console-object@4e6e32c. The comments added in DeveloperToolsWG/console-object@51e0533 say it came from Firebug.

There are some internal uses of console.exception in Firefox, but I suspect they can all switch over to console.error. Github search at https://github.com/search?l=JavaScript&q=console.exception&type=Repositories&utf8=%E2%9C%93 finds no uses. So removal is at least plausible.

And yes, @bgrins is a better contact for devtools.

[xirzec]

Interestingly, console.exception isn't injected by the tools today. It appears the function is provided by the web platform and the tools don't override it. All it seems to do is alias console.error, though calling it with a custom this doesn't do the right thing. I'll let @TheLarkInn comment on usage telemetry.

[bgrins]

I'm asking for feedback from the Firefox devtools / web compat teams about console.exception and will respond back here ASAP.

[miketaylr]

There are some internal uses of console.exception in Firefox, but I suspect they can all switch over to console.error. Github search at https://github.com/search?l=JavaScript&q=console.exception&type=Repositories&utf8=%E2%9C%93 finds no uses. So removal is at least plausible.

The search @ https://github.com/search?l=JavaScript&p=5&q=%22console.exception%22&type=Code&utf8=%E2%9C%93 (with quotes) turns up some usage:

• https://github.com/TyDraniu/from-selector-to-bookmark-title/blob/8264456afe689a77ee79e45e47f1a437aa4c1d27/data/script.js
• https://github.com/silkimen/browser-polyfill/blob/c0ab32f239029eb3ddee9b6e10f5c62d646d63aa/polyfills/console/exception/tests.js#L8 (this one might be polyfilled?)
• https://github.com/liushuirenjialian/luodiyeDemo/blob/e2a664309a4b4d48a6bafe09a703ce74d4b012e9/js/vendor/polyfills/console/exception/tests.js#L8

I think we should attempt telemetry before removing it (or possibly disable it in non-release builds for a few releases to sniff out bustage).

[domfarolino]

Thanks @TheLarkInn and @bgrins, excited to see the telemetry on this. The issue Mike linked to looks good and will probably give us some good insight on future decisions with this spec as well.

[domfarolino]

I've created web-platform-tests/wpt#10124 so we can assert the non-existence of markTimeline.

For those interested, as @bgrins mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1440729, Firefox telemetry for the Console methods can be viewed here: https://georgf.github.io/usecounters/index.html#kind=page&group=CONSOLE&channel=beta&version=60.

Any update on Edge's end @TheLarkInn ?

[bgrins]

In response to #27 (comment) and #27 (comment):

We've gathered data on console API usage in Firefox 60 beta and are seeing virtually 0 usage of console.exception (https://bugzilla.mozilla.org/show_bug.cgi?id=1440729#c19). No objections from us to remove it from the spec.

[bgrins]

By the way, if other browsers collect console API usage data I'd be interested to compare with the Firefox telemetry use counters at https://georgf.github.io/usecounters/index.html#kind=page&group=CONSOLE&channel=beta&version=60.

[domfarolino]

Sounds good. It doesn't exist in the spec right now, so I think with 0 usages in Chrome + Safari (they don't implement it) and ~no usages in Firefox, I think it's safe to leave it out and have implementations remove their versions. Closing this issue now, if Edge has any compelling data pointing in a different direction we can revisit. I'll open a separate issue for timeStamp.

Thanks a lot everyone!