Hi,
helpful exception messages are very important, and ensuring that
sufficient context is present is a good contribution to that. Thanks
for pushing this forward!
When starting work on replacing uses of the deprecated
ErrorResult::Throw(nsresult), I noticed that the existing error
messages show
On 2/10/20 9:57 AM, Anne van Kesteren wrote:
Would using Document.prototype.getElementById be too long?
That is a good question.
I'm going to do a bit of refactoring so we only need to change one place
to try these ideas out and would love some feedback!
In the meantime, someone who wants t
On Mon, Feb 10, 2020 at 3:23 PM Boris Zbarsky wrote:
> You can test this now in the console using:
>
>CSS.escape() /* no args */
>document.getElementById() /* no args */
>
> My changes did not affect the error messages from those, note; just used
> that same string in more places.
Would u
Hello all,
We just made some changes to how exception strings from ErrorResult get
formatted [1]. The changes apply to both the Throw* DOMException
methods and ThrowTypeError/ThrowRangeError.
In the new setup, exception messages have "%s: " prepended to them,
where %s is replaced with one o
On 2/8/20 2:31 PM, Domenic Denicola wrote:
Would you consider using something that avoids the confusion with static
methods/properties? E.g.
- InterfaceName's methodName()
- InterfaceName's attrName getter
- InterfaceName's attrName setter
We could think about doing that, yes. If we do, we s
On Friday, February 7, 2020 at 8:55:45 AM UTC-5, Boris Zbarsky wrote:
> Hello all,
>
> We just made some changes to how exception strings from ErrorResult get
> formatted [1]. The changes apply to both the Throw* DOMException
> methods and ThrowTypeError/ThrowRangeError.
>
> In the new setup,
6 matches
Mail list logo
