This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html Multipage: http://www.whatwg.org/C#close-the-dialog Complete: http://www.whatwg.org/c#close-the-dialog Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Why throw instead of no-op when open="" is absent? Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.112 Safari/537.36 OPR/20.0.1387.51 (Edition Next)
Because if you call close() on a closed dialog, you almost certainly have a coding error, and throwing an exception lets you find out exactly where the error is with a stack trace. But I could go either way. Should we change this?
I figured that since the user can close dialogs with "escape", it could complicate things for the app developer and might result in cargo-cult always checking if the dialog is open before calling close() or using try/catch. As for coding errors, would it also be a coding error to close a modal dialog that is not the top-most modal dialog?
(In reply to Simon Pieters from comment #2) > I figured that since the user can close dialogs with "escape", it could > complicate things for the app developer and might result in cargo-cult > always checking if the dialog is open before calling close() or using > try/catch. Yeah, I could see this going either way. > As for coding errors, would it also be a coding error to close a modal > dialog that is not the top-most modal dialog? Probably... Anyone else have an opinion? If nobody has anything else to add, I'll probably go with zcorpan's suggestion.
Trying to gather more feedback here: https://twitter.com/zcorpan/status/461067952100741120
I agree with zcorpan. Not having `close()` throw greatly simplifies scripts.
This should not throw. Tasks/microtasks want to race on closing the dialog without try/catch. Same with exitFullscreen() and a dozen other APIs.
Checked in as WHATWG revision r8591. Check-in comment: dialog.close() shouldn't throw http://html5.org/tools/web-apps-tracker?from=8590&to=8591
Chromium issue https://bugs.chromium.org/p/chromium/issues/detail?id=638943