On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > Originally it seemed that you are working under the assumption that most > sites are overriding our default newline handling behavior. This is > very easy to measure through telemetry by adding a probe for example > that looks when an HTML editor object is destroyed whether the > defaultParagraphSeparator command was used to override our default > behavior, you can send a value of 0 for the false case and a value of 1 > for the true case and we can get a percentage of pages where this > override actually happens on based on this data.
I think I wasn't clear. By "overriding" I meant that when the user presses Enter, they intercept the keystroke and modify the DOM themselves, and the editor code is never invoked. I didn't mean that the sites alter defaultParagraphSeparator. So we could add a probe that detects when the editor's Enter-handling code is run at all. >> 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? > > Detecting the actual breakage that can happen is much more difficult in > code because you would need to first define what the breakage would > result in to try to detect it in code which is extremely difficult in > this case. If we had a list of top sites that used our Enter-handling code, we could test them manually. (But such testing would be unlikely to be comprehensive.) > Getting the kind of data I'm suggesting above _now_ that the patch is > landed seems rather pointless. There seems to be a lot of disagreement > on the degree of the risk involved in this change in the first place, > and until we agree on the level of risk arguing about the details like > this may be pointless. It's not pointless if we pref it only to Aurora, and leave it there until we have more data. > At the end of the day, this is Masayuki's call. I certainly understand > that in the past with changes like this we've had a lot of difficulty > detecting regressions before the patches have hit the release channel, > so I'm not sure how much keeping the patch on pre-release channels would > really help. :-( But to me it seems like the kind of thing that we'd > want to be able to quickly turn off on the release channel through > shipping a hotfix add-on that sets a pref if something goes wrong... FWIW, changing the default back to <br> is a one-line change already. > Perhaps I'm missing something about the nature of what changed here. > How is this seldom used? Am I misunderstanding that the change happened > was how *Gecko* reacts to the user pressing Enter by default in a > contenteditable section? It's true that some editing widgets override > this behavior somehow, but I'd be really shocked if that's true 100% of > the time, so I don't understand how you argue this is a seldom used > feature... Yes, I do mean that AFAIK high-profile editing frameworks do override this kind of behavior. Johannes Wilm seems to be the founder of the "Fidus Writer" editor project, and when I asked "Do editors all override hitting Return, Backspace, etc.?" he said "Those involve taking apart and merging paragraphs, so I cannot really imagine how one would create an editor without doing that. At the very least one will need to monitor what the browser does and then adjust if needed." <https://github.com/w3c/editing/pull/146#issuecomment-242434100> The second sentence is what we have to worry about, though. One thing I know for sure is, when I looked into it several years ago, execCommand() usage among high-profile editors seemed to be nonexistent. Once you're writing all the code yourself to handle styling and block formatting and so on, overriding the behavior for hitting Enter is a no-brainer. It wouldn't be hard to test whether various sites use our built-in linebreak behavior when the user hits Enter. Just put a printf in the relevant function and see if it gets hit. Maybe I'll do that. > I guess I'm personally coming from the perspective of having bitten by > regressing various things about the editor behavior too many times in > the past, and every time it happened, we could make an argument about > how it's extremely unlikely to happen beforehand. :-) Yes, on reconsideration, I expect some fallout. Phasing this in more cautiously seems like a good idea to me. I think it might be best to just leave it in Aurora and Beta for longer than usual before promoting it. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
