This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec says "TODO: Define behavior for show UI." in a comment. In Blink, the showUI argument does nothing, but there are two fixes: In executeCreateLink: // FIXME: If userInterface is true, we should display a dialog box to let the user enter a URL. In executeInsertImage: // FIXME: If userInterface is true, we should display a dialog box and let the user choose a local image. Since not implementing these seems Web compatible, I suggest making showUI explicitly do nothing, required merely for legacy compat.
In Gecko, passing true to showUI will cause the method to return false unconditionally. Your suggestion (ignoring showUI) kind of breaks Gecko's behavior. Are you OK with doing the more conservative thing (returning false in Blink) and spec'ing that?
I think this is the code in question: https://github.com/mozilla/gecko-dev/blob/97c5c90a44a409e65f590418deca4bc93eb5bdc3/dom/html/nsHTMLDocument.cpp#L3176 I have no strong opinions about how execCommand() should work, I'm guessing that in IE this argument actually caused UI to be shown and that we thus have three different models. For Gecko start doing something in the showUI=true case and for Blink to stop doing something in the showUI=true seem approximately as risky. Checking what IE does might help us figure out what's likely to be more compatible. I could add a use counter for the showUI=true case to get a rough idea of the risk. Is it possible to do the same in Gecko, since we may not be getting the same codepaths?
(In reply to Philip Jägenstedt from comment #2) > I think this is the code in question: > https://github.com/mozilla/gecko-dev/blob/ > 97c5c90a44a409e65f590418deca4bc93eb5bdc3/dom/html/nsHTMLDocument.cpp#L3176 That's correct. > I have no strong opinions about how execCommand() should work, I'm guessing > that in IE this argument actually caused UI to be shown and that we thus > have three different models. Yes, and it still does. See this test case in IE, for example: <http://people.mozilla.org/~eakhgari/execcommand-ui.html> However, given the number of editor widgets implemented in JS which accomplish this with their own UI, I don't think the browser default UI is worth implementing. > For Gecko start doing something in the showUI=true case and for Blink to > stop doing something in the showUI=true seem approximately as risky. > Checking what IE does might help us figure out what's likely to be more > compatible. Hmm, yeah I guess it really depends on what the observable behavior difference is. There is an observable difference in Gecko (execCommand returning false.) Is there one in Blink? Or is showUI *silently* ignored? > I could add a use counter for the showUI=true case to get a rough idea of > the risk. Is it possible to do the same in Gecko, since we may not be > getting the same codepaths? Unfortunately we don't have a good counterpart for Blink's use counters yet. :( We are working on one, but it will be some time before it's enabled on the release branch in a useful way... I'd be happy to do this once the infrastructure is there, of course.
In Blink, the showUI argument is passed around, but never actually used. Stumbling upon this oddity is what prompted me to file this bug. I guess in IE there are lots of commands that never show UI. Do those return false early like Gecko does when showUI is true? If not, the current behavior of Blink/WebKit seems pretty reasonable, and is as simple as it can be.