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