[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 #20 from Aryeh Gregor <ayg at aryeh.name>  2012-04-17 23:43:19 PST ---
(In reply to comment #19)
> It appears that immediate compatibility risk is minimal for these. I'm not sure of usefulness of such exceptions though. Looking at the same example, who would want queryCommandState("LiveResize") to raise an exception? Inconsistency between closely related functions is not great, too.
> 
> Do you have an example where it would make more sense?

The issue is that WebKit's behavior means queryCommand*() will silently return bogus results for unsupported commands.

> Looking at it from a different angle, I'm not sure what the frame of this discussion is. Are we talking about extending the set of execCommand verbs, so there will be a transition period for each new one? Because everyone already implements what makes sense, and silently ignoring other known verbs is the right answer. For instance, we'd likely need to add dummy implementations of LiveResize and ClearAuthenticationCache just to avoid possible exceptions.
> 
> And if we're talking about new verbs, then raising exceptions has major compatibility consequences for everyone, including engines that have always been raising exceptions. The risk is not about changing the wording in the spec, but about how badly IE would break on a site calling execCommand("ExperimentalHTML5MobileOnlyHotness"). The fact that IE always raised exceptions is irrelevant when sites actually start executing commands not supported by it.

Most web APIs throw if given invalid input -- in particular, practically all DOM methods throw on failure.  You're right that this doesn't make as much sense if browsers implement different feature-sets.  But it's also bad that if an author writes document.execCommand("insertHoriznotalRule") it will silently fail and it will possibly take them a long time to figure out what's wrong.

So with respect to the legacy IE commands, we could always spec those commands as doing nothing rather than throwing.  That way authors can still catch typos quickly.  If we weren't introducing new commands, I think this would clearly be the best solution.

It's true that we're introducing new commands too, e.g., defaultParagraphSeparator.  If someone writes a page in a browser that supports it, they won't add try/catch, so it will break in other browsers.  But is this really any different from if we add new methods?  If authors call Selection.extend, it will work in Gecko and WebKit but fail in IE.  Does this mean that we should fail silently when authors call undefined methods?  This is not how the web platform works.  If authors use new features in a browser that doesn't support them, it normally throws.

So I'd say we should whitelist all the legacy IE commands and make them fail silently (return false).  But other unrecognized commands should throw, just like any new features that aren't implemented yet.  How does that sound to everyone?  IE already does something like that, so if Gecko or WebKit is willing to go with that, I'll spec it as the majority position.

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