Re: Intent to change editor newline behavior

On Thu, Apr 6, 2017 at 3:34 PM, Ehsan Akhgari 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 som

Re: Intent to change editor newline behavior

On 2017-04-06 7:51 AM, Aryeh Gregor wrote: > On Wed, Apr 5, 2017 at 11:22 PM, Daniel Veditz 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 ba

Re: Intent to change editor newline behavior

On Wed, Apr 5, 2017 at 11:22 PM, Daniel Veditz 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

Re: Intent to change editor newline behavior

On Wed, Apr 5, 2017 at 7:14 AM, Aryeh Gregor 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 def

Re: Intent to change editor newline behavior

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 ___ dev-pl

Re: Intent to change editor newline behavior

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

Re: Intent to change editor newline behavior

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

Re: Intent to change editor newline behavior

On 2017-04-05 7:27 AM, Aryeh Gregor wrote: > On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari 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

Re: Intent to change editor newline behavior

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

Re: Intent to change editor newline behavior

On 4/5/17 9:12 AM, Ehsan Akhgari wrote:> On Tue, Apr 4, 2017 at 11:31 AM, Aryeh Gregor > > wrote: > > On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari > mailto:ehsan.akhg...@gmail.com>> wrote: > > I don't own this module any more, so this isn't my call to make, b

Re: Intent to change editor newline behavior

On Tue, Apr 4, 2017 at 8:12 PM, Ehsan Akhgari wrote: > I doubt it's used much. My assumption is only that not many sites are >> UA-sniffing Firefox, finding the s, and modifying them in some way >> that breaks if they're no longer s. That could still be totally >> wrong, though! >> > > Exactly

Re: Intent to change editor newline behavior

On Tue, Apr 4, 2017 at 11:31 AM, Aryeh Gregor wrote: > On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari > 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

Re: Intent to change editor newline behavior

On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari 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 n

Re: Intent to change editor newline behavior

On 2017-04-04 7:55 AM, Aryeh Gregor wrote: > On Mon, Apr 3, 2017 at 11:39 PM, Benjamin Smedberg > 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 li

Re: Intent to change editor newline behavior

On Mon, Apr 3, 2017 at 11:39 PM, Benjamin Smedberg 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

Re: Intent to change editor newline behavior

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 k

Intent to change editor newline behavior

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