[Webkit-unassigned] [Bug 188696] beforeunload interoperability issues with a throwing return

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188696

--- Comment #19 from Darin Adler <darin at apple.com> ---
(In reply to PhistucK from comment #17)
> Huh, would you have added/thought about adding that test if I did not write
> that mistake?

Yes. I am deeply invested in creating more tests about JavaScript side effects and exceptions. This is an area we often don’t cover sufficiently in our testing and is easy to get wrong. Such mistakes can create interoperability problems between web browsers and security vulnerabilities. But I also find it inelegant and aesthetically repugnant to have side effects that occur in a unpredictable order or code that runs after an exception has been raised.

> Is there such a test for every case that implicitly/explicitly
> calls toString?

No.

> If not, do you think there should be one for every case?

I do.

> It seems to me that this would inflate the test suite considerably

This does not worry me.

> (and maybe
> also should be handled at the compiled IDL binding level instead somehow).

If you mean that the code to handle issues like this one should be generated from IDL whenever possible, I agree. It’s trickier to get this right in cases that are hand-written rather than generated. But of course we are having this discussion in the context of a case where this is hand-written code, and is not generated.

If the code was generated we might decide we don’t need individual test coverage for all the generated cases. Or maybe not, it’s possible we can cover all the cases efficiently and so it’s worth doing do. Typically it’s not a challenging trade-off. With a few exceptions, more tests usually do work out to be affordable.

If you mean that the code to *test* these cases should be generated from IDL whenever possible, yes, I agree that is a good strategy too. But again it’s not a reason not to write a single test when we aren’t yet generating such things.

> I do not mind having such a test (of course it would have caught my
> mistake), I just wonder if you think such practice should be extremely
> widespread.

I do.

> (I do understand my mistake exists/existed in the code base for other cases
> that you had to fix, which is probably what prompts the request for such a
> test)

Exactly.

Our strategy in this project is to test modified code which we had to visit to fix a bug or add a feature even *more* thoroughly than the rest of the code in the project; in many cases doing this then leads, either directly or indirectly, to thoroughly testing the similar issue across many or all cases.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180824/66ed9479/attachment.html>