[webkit-dev] Improving DOM Exception console messages.

[Mike West]

Thanks for the discussion, I'm happy this sparked some interest.

TL;DR: I'd like to strawman up a patch to talk more concretely about
implementation (webkit.org/b/98050 if you'd like to follow along), and
I'll start a
thread on www-dom to hammer out questions of interop.

On Mon, Oct 1, 2012 at 7:45 PM, Darin Adler <darin at apple.com> wrote:

> I think the naming here is critical.
>
> <snip entirely reasonable critique of "context">
>
> So we need different names. Perhaps detailedDescription and
> detailedDescriptionForLocalUseOnly? That second name is super-long so probably
> bad, and it doesn’t make the end user privacy aspect clear.

"detailedDescription" and "redactedDescription"? The latter seems to carry with
it the connotation that missing detail was removed due to concerns over security
or privacy.

>> At each setDOMException callsite, we'd have to provide some mechanism for
>> setting one or both strings.
>
> I’m interested in what this would be. I worry about creating two string
> objects every time, especially when the caller is not the DOM itself and will
> be simply destroying those strings without inspecting them.

I'd expect the majority of the callsites to set only one string:
"detailedDescription" from above. Only those callsites dealing in information we
consider sensitive should set the other string.

In general, however, you're correct: this change would involve generating more
strings than we're currently generating, and we should consider the impact. I
hope the benefit to developers will end up outweighing any hit we take.

> Seems like an acceptable basic approach, but will be a huge change covering
> tons of call sites. This is something we should be careful to do deliberately
> while thinking about and measuring the performance impact and readability
> impact.

Yes, it looks like it would touch about ~1,500 callsites in ~350 files.

I'd like to put together a strawman for discussion that takes one
uninterestingexception, and one with security implications all the way
through to evaluate
how this change might look, but it's not a change I'd want to land all at once.



On Mon, Oct 1, 2012 at 7:52 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> Where is this spec'ed? If we're exposing this to the Web, we definitely a
> spec. for this BEFORE implementing it in WebKit.

I don't think Ojan is entirely correct in saying that there's no spec. He's
correct that no single document exists that outlines all the specific error
conditions that a browser can encounter, but the set of generic conditions is
specified in DOM core[1], and other specifications reference that spec when
detailing specific errors. The selectors API spec, for instance, points to
SYNTAX_ERR in it's processing rules[2].

I'm happy to carry this conversation over to www-dom, but I do hope tha
discussion wouldn't block changing messages in the inspector, which we generally
seem to agree is both valuable and uncontrovercial. In particular, the error
stack proposal Brendan pointed out seems to be trying to solve a different
problem than the one I'd like to address. I'm all for giving developers even
more detail, but the proposal I'm making right now is really about giving them
the bare minimum.

Thanks!

-mike

[1]: http://www.w3.org/TR/dom/#domexception
[2]: http://www.w3.org/TR/selectors-api/#processing-selectors