[Webkit-unassigned] [Bug 83993] Unsupported commands in execCommand/queryCommand* should throw except queryCommandSupported

[bugzilla-daemon at webkit.org]

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





--- Comment #28 from Aryeh Gregor <ayg at aryeh.name>  2012-04-22 02:03:43 PST ---
(In reply to comment #25)
> I don't think that you explained how this is different from setProperty. The situation is pretty much the same - we have an extensible set of commands, and don't raise exceptions. Are you just saying that it's an outlier?

Yes, the platform is inconsistent.  More examples:

* HTMLCanvasElement.getContext().  This returns null instead of an object if the canvas type is unsupported.  This means that if you don't check for errors, you'll get an exception as soon as you try to call any method on the returned canvas.  (To be fair, real silent failure here would be close to impossible given that calling an unknown method fails, so it's not much of an argument either way.)

* XMLHttpRequest.responseType: I'm told this silently ignores setting to invalid types.

* createElement(), setAttribute(), etc.: It's hard to say how to classify these.  They succeed but might not do what you expect, so maybe it should be called silent failure.  But you could also say that it's a deliberate feature that you can create elements/attributes with any name, so it's not failure at all if it does nothing special.

In #whatwg, annevk thought not throwing was the better option given a choice.  At this point I'm kind of ambivalent.  If we don't throw, execCommand() should still return false for an unsupported command or value (in cases like foreColor where weird values cause aborts).  I guess then queryCommand*() shouldn't throw either, for consistency, although neither IE nor Gecko behaves this way.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.