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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 17 09:19:13 PDT 2012


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





--- Comment #19 from Alexey Proskuryakov <ap at webkit.org>  2012-04-17 09:19:12 PST ---
> But for queryCommandIndeterm/State/Value, we can still throw -- this is what both IE *and* Gecko have always done

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?

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.

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



More information about the webkit-unassigned mailing list