Intent to change editor newline behavior

[Aryeh Gregor]

In our rich-text editor (used in Firefox for designMode and
contenteditable), when the user hits Enter, we have historically always
inserted a <br>. This does not match any other browsers, which use <p> or
<div> as line separators. In bug 1297414, I'm changing our behavior to use
<div> as a line separator. This matches Blink/WebKit.

So if you have the text "foobar" and hit Enter in between the "foo" and the
"bar", previously you would get "foo<br>bar", and soon you will get
"<div>foo</div><div>bar</div>". The defaultParagraphSeparator command can
be used to change the separator to "p" instead (which matches Edge's
default behavior last I checked).

Pages or embedders that want to keep the old behavior can run the following
command: document.execCommand("defaultParagraphSeparator", false, "br").

This change is not likely to affect high-profile sites that use rich-text
editing (webmail etc.), because due to browser incompatibility, these sites
all override this behavior anyway.

Our new behavior is as specified in the essentially unmaintained editing
specification that I wrote several years ago, and tested by the
web-platform-tests editing suite. (Except that the "br" value to
defaultParagraphSeparator is unspecified, and is a Mozilla-specific
extension for backwards compatibility.)

[Benjamin Smedberg]

I'd like to encourage you to set up a test plan for this. My impression of
the risk profile of this work is that we could easily break some really
important use-cases, and it's likely that sites customize for gecko
behavior and rely on it, either accidentally or on purpose. This is
definitely the kind of thing that would be worth rolling out carefully and
perhaps slowly. Will this behavior be behind a pref which is easy to flip,
test, and roll out?

--BDS

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Aryeh Gregor]

On Mon, Apr 3, 2017 at 11:39 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
>
> I'd like to encourage you to set up a test plan for this. My impression of the risk profile of this work is that we could easily break some really important use-cases, and it's likely that sites customize for gecko behavior and rely on it, either accidentally or on purpose. This is definitely the kind of thing that would be worth rolling out carefully and perhaps slowly. Will this behavior be behind a pref which is easy to flip, test, and roll out?

As implemented, it is not behind a pref. Masayuki didn't request a
gradual rollout, so I pushed to inbound already. I suspect it will
not actually break anything, because sites that use the editor
normally avoid browser compatibility issues here by completely
overriding the newline behavior, so they will be unaffected. If any
sites actually do break from this, I would be very interested to have
the data that people are really using our default newline behavior!

I'd like to know what Ehsan and Masayuki think about the likely compat
impact here.

[Ehsan Akhgari]

I think this is a very risky change. While some editor widgets may
already be UA sniffing Gecko and using the defaultParagraphSeparator
command already, others may be relying on us injecting a <br> by default
and be fixing up the DOM after the fact, and those widgets could
potentially break in all kinds of potentially surprising ways as a
result of this change. Unfortunately, historically many of the bugs
like this only get reported to us very late in the beta cycle (or even
after the change gets to the release channel.)

I don't own this module any more, so this isn't my call to make, but if
I had to choose what to do here, I would probably either choose to not
change our behavior (since I'm not sure what we're gaining here
concretely -- as AFAIK we're not investing in bringing our behavior on
par with other engines on a more broad basis with regards to editing),
or at the lack of that, adding some telemetry first to get data on how
often the defaultParagraphSeparator command is used in the wild, since
AFAICT your change is basically only Web compatible on the assumption
that this command is used quite heavily. I'll also note that detecting
what breaks here isn't even easy when the defaultParagraphSeparator
command has not been executed, so the telemetry data indicating where
that command has _not_ been executed can't necessarily account for the
cases where your change could cause potential issues.

On the idea of the test plan that Benjamin brought up, I'm not sure what
to put in such a test plan, due to the issue I mentioned above (it being
totally non-obvious what the expected breakage of this change would look
like.)

Cheers,
Ehsan

[Aryeh Gregor]

On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> I don't own this module any more, so this isn't my call to make, but if
> I had to choose what to do here, I would probably either choose to not
> change our behavior (since I'm not sure what we're gaining here
> concretely -- as AFAIK we're not investing in bringing our behavior on
> par with other engines on a more broad basis with regards to editing),

Masayuki seems to be in favor of trying to match Blink more.

> or at the lack of that, adding some telemetry first to get data on how
> often the defaultParagraphSeparator command is used in the wild, since
> AFAICT your change is basically only Web compatible on the assumption
> that this command is used quite heavily.

I doubt it's used much. My assumption is only that not many sites are
UA-sniffing Firefox, finding the <br>s, and modifying them in some way
that breaks if they're no longer <br>s. That could still be totally
wrong, though!

> On the idea of the test plan that Benjamin brought up, I'm not sure what
> to put in such a test plan, due to the issue I mentioned above (it being
> totally non-obvious what the expected breakage of this change would look
> like.)

We could put the default defaultParagraphSeparator change behind a
pref and leave the pref off on release (or on beta and release?) for
some period and see if we get bug reports. I don't think there's any
way to detect breakage by telemetry, so we'd have to rely on user
reports.

[Ehsan Akhgari]

On Tue, Apr 4, 2017 at 11:31 AM, Aryeh Gregor <a...@aryeh.name> wrote:

> On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
> > I don't own this module any more, so this isn't my call to make, but if
> > I had to choose what to do here, I would probably either choose to not
> > change our behavior (since I'm not sure what we're gaining here
> > concretely -- as AFAIK we're not investing in bringing our behavior on
> > par with other engines on a more broad basis with regards to editing),
>
> Masayuki seems to be in favor of trying to match Blink more.
>

Masayuki's opinion here certainly outweighs mine. :-)

> > or at the lack of that, adding some telemetry first to get data on how
> > often the defaultParagraphSeparator command is used in the wild, since
> > AFAICT your change is basically only Web compatible on the assumption
> > that this command is used quite heavily.
>
> I doubt it's used much. My assumption is only that not many sites are
> UA-sniffing Firefox, finding the <br>s, and modifying them in some way
> that breaks if they're no longer <br>s. That could still be totally
> wrong, though!
>

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?

> > On the idea of the test plan that Benjamin brought up, I'm not sure what
> > to put in such a test plan, due to the issue I mentioned above (it being
> > totally non-obvious what the expected breakage of this change would look
> > like.)
>
> We could put the default defaultParagraphSeparator change behind a
> pref and leave the pref off on release (or on beta and release?) for
> some period and see if we get bug reports. I don't think there's any
> way to detect breakage by telemetry, so we'd have to rely on user
> reports.
>

This may be a good idea as well.

We should also notify the Web Compatibility team. CCing Mike Taylor as
proxy. :-)

--
Ehsan

[Benjamin Smedberg]

On Tue, Apr 4, 2017 at 8:12 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> I doubt it's used much. My assumption is only that not many sites are
>> UA-sniffing Firefox, finding the <br>s, and modifying them in some way
>> that breaks if they're no longer <br>s. That could still be totally
>> wrong, though!
>>
>
> 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?
>

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.

--BDS

[Masayuki Nakano]

On 4/5/17 9:12 AM, Ehsan Akhgari wrote:> On Tue, Apr 4, 2017 at 11:31
AM, Aryeh Gregor <a...@aryeh.name

> <mailto:a...@aryeh.name>> wrote:
>
> On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> wrote:
> > I don't own this module any more, so this isn't my call to
make, but if
> > I had to choose what to do here, I would probably either choose
to not
> > change our behavior (since I'm not sure what we're gaining here
> > concretely -- as AFAIK we're not investing in bringing our
behavior on
> > par with other engines on a more broad basis with regards to
editing),
>
> Masayuki seems to be in favor of trying to match Blink more.
>
>
> Masayuki's opinion here certainly outweighs mine. :-)

Yeah, I like better to make our behavior more compatible with other
browsers if the other behavior does make sense (or at least it's not
"not makes sense"). Our current market share doesn't have so many
impact for web developers. Therefore, I worry about that if we keep
compatibility with older Gecko rather than other browsers, new web
services would not support Gecko due to the market share vs.
implementing cost.

> > On the idea of the test plan that Benjamin brought up, I'm not
sure what
> > to put in such a test plan, due to the issue I mentioned above
(it being
> > totally non-obvious what the expected breakage of this change
would look
> > like.)
>
> We could put the default defaultParagraphSeparator change behind a
> pref and leave the pref off on release (or on beta and release?) for
> some period and see if we get bug reports. I don't think there's any
> way to detect breakage by telemetry, so we'd have to rely on user
> reports.
>
>
> This may be a good idea as well.

I doubt it partially. In my latest experience, most testers use
pre-release bulds silently. I usually get regression reports after
reaching risky patch to the release especially when it's limited to
non-English users.

So, in this case, I think we'd get regression reports of web apps which
is used in world wide. Otherwise, we wouldn't get regression reports
until releasing the new behavior.

# Sorry I posted same message from outside of dev-platform.

--
Masayuki Nakano <masa...@d-toybox.com>
Software Engineer, Mozilla

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari <ehsan....@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 <benj...@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).

[Ehsan Akhgari]

On 2017-04-05 7:27 AM, Aryeh Gregor wrote:

> On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari <ehsan....@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.

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.

> 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 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.

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.

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...

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...

> 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).

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. :-) In my
experience, regressions affecting this code are usually of two kinds,
they either are severe enough that they break *many* sites and you'll
get a few bug reports on the Nightly channel after a few days, or you
basically don't hear about them at all until late during the beta cycle
or when the patch hits the release channel. Manually testing sites and
libraries, while useful, only covers a tiny surface of what's needed,
since a lot of the editor libraries have lots of old versions that are
used in the wild and they all have their own behaviors and they rarely
get updated, so it's not just a matter of testing the latest version of
a few libraries and sites. And often times the older and smaller
websites tend to use more of the browser functionality and the larger
sites tend to implement more of their own functionality on top of the
raw DOM APIs which creates an unhelpful dynamic where the sites that are
less likely to be tested in our pre-release channels are more likely to
break by these changes, etc. :-/

Anyways, I hope this is all helpful.

Cheers,
Ehsan

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari <ehsan....@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.

[Boris Zbarsky]

On 4/5/17 10:14 AM, Aryeh Gregor wrote:
> On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> 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.

The difference is that a hotfix addon does not involve people restarting
their browser to pick up an update, don't involve creating a new
release, etc, etc.

-Boris

[Mike Taylor]

On 4/4/17 7:12 PM, Ehsan Akhgari wrote:
> We should also notify the Web Compatibility team. CCing Mike Taylor as
> proxy. :-)

Thanks -- I've let the team know to be on the lookout for new editor-ish
bugs.

--
Mike Taylor
Web Compat, Mozilla

[Daniel Veditz]

On Wed, Apr 5, 2017 at 7:14 AM, Aryeh Gregor <a...@aryeh.name> wrote:

> > 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.
>

​One line or a thousand isn't the point; building, release and update
testing, and shipping 90 locales times 6 platforms​ is a huge amount work.
If we have a pref and break something we can back it out easily and
quickly. We could even do a slow roll-out independent of a release if we're
extra concerned about compat (as we have done with e10s and sha1
deprecation, for example).

-Dan Veditz

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 11:22 PM, Daniel Veditz <dve...@mozilla.com> wrote:
> One line or a thousand isn't the point; building, release and update
> testing, and shipping 90 locales times 6 platforms is a huge amount work. If
> we have a pref and break something we can back it out easily and quickly. We
> could even do a slow roll-out independent of a release if we're extra
> concerned about compat (as we have done with e10s and sha1 deprecation, for
> example).

Then it certainly sounds good to make this a pref. I filed bug 1354060.

Incidentally, bug 1353913 proves that Gmail does use our line-breaking
behavior, and so presumably so do other editors.

[Ehsan Akhgari]

Thanks for the follow-ups and for filing bug 1354060. But now that we
know that this affected Gmail, I'll note that the risk around this is
still there, and while keeping this on the pre-release channels for a
while reduces the risk somewhat, we should still be super careful when
we decide to let it go to release, and preferably do so in coordination
with the Web Compat team and in preparation to deal with any fallout. :-)

[Aryeh Gregor]

On Thu, Apr 6, 2017 at 3:34 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Thanks for the follow-ups and for filing bug 1354060. But now that we
> know that this affected Gmail, I'll note that the risk around this is
> still there, and while keeping this on the pre-release channels for a
> while reduces the risk somewhat, we should still be super careful when
> we decide to let it go to release, and preferably do so in coordination
> with the Web Compat team and in preparation to deal with any fallout. :-)

I agree that it makes sense to not let this ride the trains at the
normal pace. I guess it's Masayuki's decision how exactly to proceed.
(At any rate, it's certainly not mine, thankfully. :) )