You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The definition's prose indicates that the "If aborted" step must be run if any steps were skipped. (And I assume therefore must not be run unless any steps are skipped?) However, in the case that the user clicks "Cancel" during the computation of φ, the 'more verbose formulation' in the example indicates that it would be valid to have the result contain the digits of π, the digits of e, the digits of φ and "Didn't finish".
I'm assuming that result isn't intended to be allowed, but I just wanted to check. Thanks!
The text was updated successfully, but these errors were encountered:
I think we could fix this by instead checking if the user pressed cancelled before appending. That formulation is black-box-indistinguishable, though if naively implemented would have much worse performance. Not sure if we need to point that out as well.
Another (verbose) fix could be to add identical "Otherwise" branches for each if statement. For the naive implementation performance risk, I think the existing note probably covers us.
Hi!
I noticed a slight disparity between the conditional abort definition and example: https://infra.spec.whatwg.org/#algorithm-conditional-abort.
The definition's prose indicates that the "If aborted" step must be run if any steps were skipped. (And I assume therefore must not be run unless any steps are skipped?) However, in the case that the user clicks "Cancel" during the computation of φ, the 'more verbose formulation' in the example indicates that it would be valid to have the result contain the digits of π, the digits of e, the digits of φ and "Didn't finish".
I'm assuming that result isn't intended to be allowed, but I just wanted to check. Thanks!
The text was updated successfully, but these errors were encountered: