Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interop 2022 and execCommand #396

Open
whsieh opened this issue Apr 14, 2022 · 4 comments
Open

Interop 2022 and execCommand #396

whsieh opened this issue Apr 14, 2022 · 4 comments

Comments

@whsieh
Copy link

whsieh commented Apr 14, 2022

From web-platform-tests/interop#17, it seems like a large chunk of editing-related WPT reveal inconsistent cross-browser behavior due to different execCommand behaviors.

execCommand is deprecated, but is still used widely on the web. Furthermore, execCommand behavior (and editing in general) behaves differently across different browsers, and even different platforms. How should we proceed with execCommand-related WPT failures?

@mbrodesser
Copy link

CC @masayuki-nakano

@travisleithead
Copy link
Member

I think this is a potential pandora's box. I wonder how much churn this area of code gets in current implemetations... if not much, then I worry about breaking online editors that may have carefully coded for each browser/OS' ideosyncracies over the years. We could be introducing a lot of churn and pain for the web... when we hope to have better solutions available in the near future (e.g., EditContext).

So, is there actual pain here, or is this a sunk cost for a limited number of online editors?

@jgraham
Copy link
Member

jgraham commented Apr 22, 2022

There is actual pain here; this is one of the top sources of site compat problems we observe in Gecko. https://bugzilla.mozilla.org/show_bug.cgi?id=1341152 has a lot of linked bugs, but there are more bugs covering observed compat issues. https://bugzilla.mozilla.org/show_bug.cgi?id=1739489 is an example of a recent high-impact bug, for which we're having to ship a site intervention, which is relating to editing events (not strictly execCommand, but related). https://bugzilla.mozilla.org/show_bug.cgi?id=1747008 is another bug where a big site (Wikipedia) was depending on specific browser behaviour and so broke in other implementations. There are more examples of course, but I hope that's enough to convince you that the hypothesis that the editing ecosystem is closely matched to existing browsers, and that therefore isn't causing users problems, isn't really supported by the data.

I also think that just leaving a big area of the web unspecififed in the hope that people eventually move to some new primitives that are themselves not yet specified is not a good way to go about the development of the platform. In the best case it will take many years for new features to displace existing ones, even assuming they fully subsume the use cases. Meanwhile improving implementation alignment on the existing features isn't as exciting but can have immediate benefits because they're already shipping.

FWIW I think (and I stress I haven't checked this with others) a likely/reasonable outcome here might be that the execCommand spec and testsuite are rewritten to match Chromium behaviour in all but the cases where Chromium is actively planning changes. Then other implemenations have a clear specification to aim at and can manage the transition using UA-specific approaches e.g. site interventions.

@jgraham
Copy link
Member

jgraham commented Apr 22, 2022

Note that I'm currently trying to set up a meeting to discuss this topic; see web-platform-tests/interop-2022-editing#1 if you'd like to be involved in that or in the general editing investigation work as part of Interop 2022.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants