On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > Exactly. We can hypothesize either way, but we certainly can't know easily > without getting some data first. But unfortunately it's not possible to > collect data about what sites are doing in terms of DOM fix-ups like this. > We can, at least, collect data about whether they are overriding the newline > behavior wholesale though. Is there any reason why we should not at least > first collect this data before changing the behavior here?
What exact data would you want? We could collect data on how often our built-in newline behavior is used, and if it's low enough we'd be confident the change is safe. If it's not so low, however, we'd need to look at the actual sites to see if they break. Can we do that somehow through telemetry, or is it a privacy problem? If someone has suggestions for the exact telemetry probe to use here, I'm happy to add one, and maybe keep the change in Aurora until we get data to make a decision. I'm not familiar enough with telemetry (either the theoretical options or our implementation) to decide what the right probe is. On Wed, Apr 5, 2017 at 3:31 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > I agree that it doesn't seem likely that telemetry can answer this sort of > question. However, we could collect data! Pick N top editing tools and > actually test their behavior. We probably can't get full confidence, but we > can get a much better picture of the risk involved. If we break (or > significantly change behavior) on five sites out of 40, that's a strong > indicator that we're going to have problems. > > As an example, have we already tested or is it in a plan to test: > google docs > basic and rich text editors on wikipedia > office 365 > github editor > common rich text editor libraries, and common CRM software (I don't have a > list) > the top hosted email sites: gmail, yahoo, hotmail/outlook, aol, icloud, > yandex > > Being able to assert, before landing this change, that it doesn't break any > of these sites, would really help in terms of making assertions about the > risk profile. I did not test this specific change on those sites. However, some years ago I did research execCommand() usage on the web, and found that high-profile richtext editors essentially didn't use it, because of browser incompatibilities. Instead, they wrote their own functions. The same incompatibilities exist in newline behavior, so it's reasonable to say that they would write their own functions for that too. This is also supported by a discussion I had with a couple of developers of major richtext editing libraries (I don't remember which offhand). They said that changes like this make no difference to them, because they don't use the functionality anyway. They're interested in fixes in things like selection handling, which they do use, and features that allow them to more easily override browser behavior. Also anecdotally, in terms of dealing with editor bugs like this -- the reports most often come from Thunderbird. Maybe Ehsan or Masayuki could weigh in too, but I think that we get very few bug reports in these parts of the editor from real-world websites. (We do get some reports in other parts of the editor, like selection/focus handling.) This also suggests websites aren't actually using this code much. (Although maybe it means they just work around our bugs already.) In fact, I dropped this patch set for a while because the feature is seldom-used enough on the web that it doesn't seem worth fixing. I get the impression that Ehsan shares this point of view. It's also worth noting that contenteditable is a very complicated feature to use in real life, particularly given browser incompatibilities, and I think almost all sites that use it are either very large or use one of the major rich-text editing libraries. If I'm correct, then we don't have to worry so much about breaking a long tail of small sites that won't get reported quickly. If Gmail, Wikipedia, TinyMCE, etc. break, we (or they) are likely to get reports soon enough. Large sites are also usually well-maintained and do their own testing, and will fix the issue quickly. (But if a library breaks, or software like MediaWiki, there will be a long tail of old sites that will remain broken even after the library is fixed, because they keep using old versions of the library.) So that's my reasoning for why I don't think this is *so* risky. But I agree that I don't really know. As I said, I'd be happy to let this stay on Aurora or beta for longer, and/or add some telemetry (if someone tells me what telemetry we want). _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
