Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-08-16 Thread Masayuki Nakano 

We put off to change this until we get enough telemetry data.

Now, we have a lot of data in Beta 62 users.  That indicates that each 
specific UI is rarely shown (< 0.5% of all HTMLEditor instances). 
However, according to operation count per HTMLEditor instance, some of 
them may be used by only a few users intentionally.


Currently, I plain:
- 63 disables the UIs by default only on Nightly and Early Beta.
- 64 disables the UIs by default on all channels.

Then, we'll provide new prefs to enable them by default forcibly. This 
allows us to collect telemetry data from testers even before web apps 
enable the UIs with execCommand explicitly.


If we'll get new telemetry data of 62 Release and it indicates we 
shouldn't change our behavior, we should cancel the changes before 
shipping the 64 release.


See the detail of current telemetry result here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1452538#c19

On 2018/04/05 15:58, Masayuki Nakano wrote:

This incompatibility is pointed by W3C's Editing API WG:
https://github.com/w3c/editing/issues/171

Gecko has some specific editing UI of HTML editor.
1. Resiziers of , , absolute positioned elements.
2. Adding new table row/column from buttons.
3. Removing existing table row/column from buttons.
4. Grabber to move absolute positioned element.

Currently, all of those UIs are not implemented by the other browsers. 
However, they are available in Gecko by default.


Therefore, web app developers need to disable those features with:
document.execCommand("enableObjectResizing",
  false, false); // #1
document.execCommand("enableInlineTableEditing",
  false, false); // #2 and #3

So, if web apps don't call them, only Firefox users can modify  or 
 elements as unexpected for their developers.


Additionally, web apps cannot disable only #4.

So, for solving this incompatibility issue, we should:
* Disable those UI by default
* But allow to enable those UI for backward compatibility
* Add new command "enableAbsolutePositionEditing" command for allowing 
to enable #4


I'm working on this incompatibility issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1449564



--
Masayuki Nakano 
Software Engineer, Mozilla

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-09 Thread Ehsan Akhgari 
Hi Masayuki,

First of all, thank you for taking on this task.  I have a few questions.

* What does the backwards compatibility story for these changes look like?
Would we end up for example throwing exceptions or returning a different
value from execCommand/queryCommandState/etc for one of the existing two
commands?  If there are any backwards compatibility concerns, what are your
plans for them?  Note that these two commands are extremely popular in
existing code that knows about Gecko (since it typically has to start off
by disabling this UI as you've noted.)

* Why are we *adding* a new command for enabling the absolute positioning
UI if we believe this UI is not useful and should be disabled?  Do we have
any indication that web developers want to use this UI in some cases, and
for Firefox only?  Have we heard any plans from other browser vendors that
they're interested to add support for similar UI in the future?  The Github
issue you linked to makes that sound unlikely.  Wouldn't it be better to
just disable the absolute positioning UI?

* What is our long term plan for this UI, do we want to keep them around or
is this us deprecating the UI with the ultimate intention of measuring
their usage so that we can eventually remove them?  I think removing this
UI is at least desirable from the implementation standpoint.  The way that
the native anonymous content this UI uses is hooked up (in
https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143)
is different than everything else inside Gecko and has historically been a
source of bugs, and we've never invested any effort to improve it since we
believed the UI wasn't really worth the investment...

Thanks,
Ehsan

On Thu, Apr 5, 2018 at 11:04 AM Masayuki Nakano 
wrote:

> This incompatibility is pointed by W3C's Editing API WG:
> https://github.com/w3c/editing/issues/171
>
> Gecko has some specific editing UI of HTML editor.
> 1. Resiziers of , , absolute positioned elements.
> 2. Adding new table row/column from buttons.
> 3. Removing existing table row/column from buttons.
> 4. Grabber to move absolute positioned element.
>
> Currently, all of those UIs are not implemented by the other browsers.
> However, they are available in Gecko by default.
>
> Therefore, web app developers need to disable those features with:
> document.execCommand("enableObjectResizing",
>   false, false); // #1
> document.execCommand("enableInlineTableEditing",
>   false, false); // #2 and #3
>
> So, if web apps don't call them, only Firefox users can modify  or
>  elements as unexpected for their developers.
>
> Additionally, web apps cannot disable only #4.
>
> So, for solving this incompatibility issue, we should:
> * Disable those UI by default
> * But allow to enable those UI for backward compatibility
> * Add new command "enableAbsolutePositionEditing" command for allowing
> to enable #4
>
> I'm working on this incompatibility issue in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1449564
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-09 Thread Ehsan Akhgari 
On Thu, Apr 5, 2018 at 11:08 PM Masayuki Nakano 
wrote:

> On 4/6/2018 2:50 AM, Ehsan Akhgari wrote:
> > Hi Masayuki,
> >
> > First of all, thank you for taking on this task.  I have a few questions.
> >
> > * What does the backwards compatibility story for these changes look
> > like?  Would we end up for example throwing exceptions or returning a
> > different value from execCommand/queryCommandState/etc for one of the
> > existing two commands?  If there are any backwards compatibility
> > concerns, what are your plans for them?  Note that these two commands
> > are extremely popular in existing code that knows about Gecko (since it
> > typically has to start off by disabling this UI as you've noted.)
>
> It *might* be possible that a few web apps (including intranet only
> apps) may allow users to resize some elements, edit table structure
> and/or move absolute positioned elements with these built-in UI only on
> Firefox. If such apps actually exist, they can enable the Gecko specific
> UI explicitly with using execCommand.  Then, we can collect actual usage
> with telemetry.
>

If such apps don't use execCommand to explicitly enable these commands,
they will be breaking with this change, wouldn't they?  If we are
interested in knowing about whether this is a problem, there's the
possibility of collecting telemetry beforehand too.  For example, we can
collect telemetry upon the usage of these UIs (i.e., when a user interacts
with them) and record information about whether the application has called
one of these commands explicitly to enable the UI beforehand.

If we don't collect this telemetry beforehand, we're effectively assuming
that the breakage of this kind will be low enough that we are considering
its risk low and acceptable.


> > * Why are we *adding* a new command for enabling the absolute
> > positioning UI if we believe this UI is not useful and should be
> > disabled?  Do we have any indication that web developers want to use
> > this UI in some cases, and for Firefox only?  Have we heard any plans
> > from other browser vendors that they're interested to add support for
> > similar UI in the future?  The Github issue you linked to makes that
> > sound unlikely.  Wouldn't it be better to just disable the absolute
> > positioning UI?
>
> I think that Gecko specific feature may cause unexpected result for web
> apps and could cause unexpected error on some web apps, then, at worst,
> Firefox is banned by UA sniffing.


Hmm, if the risk of removing this UI is so high, then shouldn't we collect
some telemetry data that shows that removing it is safe before attempting
to do so?

(FWIW I don't understand how this UI showing and not showing can break an
editing app so badly that web developers start to ban Firefox UAs.  One way
I can imagine is if they attempt to provide their own similar UI and ours
overrides it, but since we are talking about changing things to hide the UI
that we used to show, I don't think that's the risk you have in mind.)


> Making it's disabled by default but
> making it possible to enable with execCommand, we can collect actual
> usage with telemetry as I said above.
>

I think we can collect some telemetry data today.  For example, we can
collect data on how many HTML editor instantiations see the absolute
positioning UI, and also how many of the times we display this UI the user
ends up interacting with it.

The problem with adding a new command and try to collect telemetry after
that is that you're expecting Web developers to first update their code to
use the new command before any meaningful telemetry data can be gathered,
and then our hope would be that the data would suggest that the feature is
unused so that we can tell the few Web developers who did update their code
to use the new command to update it again to remove the command once we
decide to remove this UI based on low usage.  :-)


> > * What is our long term plan for this UI, do we want to keep them around
> > or is this us deprecating the UI with the ultimate intention of
> > measuring their usage so that we can eventually remove them?  I think
> > removing this UI is at least desirable from the implementation
> > standpoint.  The way that the native anonymous content this UI uses is
> > hooked up (in
> >
> https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143
> )
> > is different than everything else inside Gecko and has historically been
> > a source of bugs, and we've never invested any effort to improve it
> > since we believed the UI wasn't really worth the investment...
>
> I think that we'll get evidence which indicate nobody uses those Gecko
> specific feature, we can move those UI into comm-central or just remove
> them completely.
>

Hmm, if we want to keep them around for comm-central, then I'm not all that
certain if moving the code out of m-c is beneficial since this code impacts
the way

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-09 Thread Makoto Kato 
> * Add new command "enableAbsolutePositionEditing" command for allowing to
enable #4

There is no way to use absolute position editing on Firefox because
cmd_abspos is used by comm-central only.  So I guess that it might be
unnecessary to add this command for Firefox and is better to add a
preference to enable it as default.

-- Makoto

On Thu, Apr 5, 2018 at 3:58 PM, Masayuki Nakano 
wrote:

> This incompatibility is pointed by W3C's Editing API WG:
> https://github.com/w3c/editing/issues/171
>
> Gecko has some specific editing UI of HTML editor.
> 1. Resiziers of , , absolute positioned elements.
> 2. Adding new table row/column from buttons.
> 3. Removing existing table row/column from buttons.
> 4. Grabber to move absolute positioned element.
>
> Currently, all of those UIs are not implemented by the other browsers.
> However, they are available in Gecko by default.
>
> Therefore, web app developers need to disable those features with:
> document.execCommand("enableObjectResizing",
>  false, false); // #1
> document.execCommand("enableInlineTableEditing",
>  false, false); // #2 and #3
>
> So, if web apps don't call them, only Firefox users can modify  or
>  elements as unexpected for their developers.
>
> Additionally, web apps cannot disable only #4.
>
> So, for solving this incompatibility issue, we should:
> * Disable those UI by default
> * But allow to enable those UI for backward compatibility
> * Add new command "enableAbsolutePositionEditing" command for allowing to
> enable #4
>
> I'm working on this incompatibility issue in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1449564
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-09 Thread Masayuki Nakano 

On 4/7/2018 12:39 AM, Ehsan Akhgari wrote:
On Thu, Apr 5, 2018 at 11:08 PM Masayuki Nakano > wrote:


On 4/6/2018 2:50 AM, Ehsan Akhgari wrote:
> Hi Masayuki,
>
> First of all, thank you for taking on this task.  I have a few
questions.
>
> * What does the backwards compatibility story for these changes look
> like?  Would we end up for example throwing exceptions or
returning a
> different value from execCommand/queryCommandState/etc for one
of the
> existing two commands?  If there are any backwards compatibility
> concerns, what are your plans for them?  Note that these two
commands
> are extremely popular in existing code that knows about Gecko
(since it
> typically has to start off by disabling this UI as you've noted.)

It *might* be possible that a few web apps (including intranet only
apps) may allow users to resize some elements, edit table structure
and/or move absolute positioned elements with these built-in UI
only on
Firefox. If such apps actually exist, they can enable the Gecko
specific
UI explicitly with using execCommand.  Then, we can collect actual
usage
with telemetry.


If such apps don't use execCommand to explicitly enable these 
commands, they will be breaking with this change, wouldn't they?


Yes, it is, of course.

If we are interested in knowing about whether this is a problem, 
there's the possibility of collecting telemetry beforehand too.  For 
example, we can collect telemetry upon the usage of these UIs (i.e., 
when a user interacts with them) and record information about whether 
the application has called one of these commands explicitly to enable 
the UI beforehand.


If we don't collect this telemetry beforehand, we're effectively 
assuming that the breakage of this kind will be low enough that we are 
considering its risk low and acceptable.


Okay, I'll change the default behavior only on Nightly before landing 
and I'll file a bug to collect telemetry data before landing the patches 
for the bug.



> * Why are we *adding* a new command for enabling the absolute
> positioning UI if we believe this UI is not useful and should be
> disabled?  Do we have any indication that web developers want to use
> this UI in some cases, and for Firefox only?  Have we heard any
plans
> from other browser vendors that they're interested to add
support for
> similar UI in the future?  The Github issue you linked to makes that
> sound unlikely.  Wouldn't it be better to just disable the absolute
> positioning UI?

I think that Gecko specific feature may cause unexpected result
for web
apps and could cause unexpected error on some web apps, then, at
worst,
Firefox is banned by UA sniffing.


Hmm, if the risk of removing this UI is so high, then shouldn't we 
collect some telemetry data that shows that removing it is safe before 
attempting to do so?
I worry about some specific cases such as using Firefox as default 
browser in organization and depending on such feature. I don't worry 
about public web apps since if those features are necessary, they need 
to implement those features by themselves anyway since the other 
browsers don't have the features.
(FWIW I don't understand how this UI showing and not showing can break 
an editing app so badly that web developers start to ban Firefox UAs.  
One way I can imagine is if they attempt to provide their own similar 
UI and ours overrides it, but since we are talking about changing 
things to hide the UI that we used to show, I don't think that's the 
risk you have in mind.)


I worry about the case, if web app vendors don't want to allow users to 
modifying sizes, positions, etc, it means that only Firefox users may 
change them if they didn't disable the UI with the Gecko specific 
commands. If related applications of such web apps do not assume such 
points are changeable, they may receive complains only from Firefox 
users. It must be annoying thing for their business manager since the 
market share isn't high.



Making it's disabled by default but
making it possible to enable with execCommand, we can collect actual
usage with telemetry as I said above.


I think we can collect some telemetry data today.  For example, we can 
collect data on how many HTML editor instantiations see the absolute 
positioning UI, and also how many of the times we display this UI the 
user ends up interacting with it.


The problem with adding a new command and try to collect telemetry 
after that is that you're expecting Web developers to first update 
their code to use the new command before any meaningful telemetry data 
can be gathered, and then our hope would be that the data would 
suggest that the feature is unused so that we can tell the few Web 
developers who did update their code to use the new command to update 
it

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-09 Thread Masayuki Nakano 

On 4/6/2018 2:50 AM, Ehsan Akhgari wrote:

Hi Masayuki,

First of all, thank you for taking on this task.  I have a few questions.

* What does the backwards compatibility story for these changes look 
like?  Would we end up for example throwing exceptions or returning a 
different value from execCommand/queryCommandState/etc for one of the 
existing two commands?  If there are any backwards compatibility 
concerns, what are your plans for them?  Note that these two commands 
are extremely popular in existing code that knows about Gecko (since it 
typically has to start off by disabling this UI as you've noted.)


It *might* be possible that a few web apps (including intranet only 
apps) may allow users to resize some elements, edit table structure 
and/or move absolute positioned elements with these built-in UI only on 
Firefox. If such apps actually exist, they can enable the Gecko specific 
UI explicitly with using execCommand.  Then, we can collect actual usage 
with telemetry.


* Why are we *adding* a new command for enabling the absolute 
positioning UI if we believe this UI is not useful and should be 
disabled?  Do we have any indication that web developers want to use 
this UI in some cases, and for Firefox only?  Have we heard any plans 
from other browser vendors that they're interested to add support for 
similar UI in the future?  The Github issue you linked to makes that 
sound unlikely.  Wouldn't it be better to just disable the absolute 
positioning UI?


I think that Gecko specific feature may cause unexpected result for web 
apps and could cause unexpected error on some web apps, then, at worst, 
Firefox is banned by UA sniffing.  Making it's disabled by default but 
making it possible to enable with execCommand, we can collect actual 
usage with telemetry as I said above.


* What is our long term plan for this UI, do we want to keep them around 
or is this us deprecating the UI with the ultimate intention of 
measuring their usage so that we can eventually remove them?  I think 
removing this UI is at least desirable from the implementation 
standpoint.  The way that the native anonymous content this UI uses is 
hooked up (in 
https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143) 
is different than everything else inside Gecko and has historically been 
a source of bugs, and we've never invested any effort to improve it 
since we believed the UI wasn't really worth the investment...


I think that we'll get evidence which indicate nobody uses those Gecko 
specific feature, we can move those UI into comm-central or just remove 
them completely.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-09 Thread Masayuki Nakano 

On 4/6/2018 9:25 AM, Makoto Kato wrote:
 > * Add new command "enableAbsolutePositionEditing" command for 
allowing to enable #4


There is no way to use absolute position editing on Firefox because 
cmd_abspos is used by comm-central only.  So I guess that it might be 
unnecessary to add this command for Firefox and is better to add a 
preference to enable it as default.


No, try this:

1. Go to https://d-toybox.com/studio/lib/input_event_viewer.html
2. Input "div" into 
the first  next to .

3. Select the radio button labelled .
4. Click black border box under the toolbars.

Then, you'll see grabber to move the black border box at top edge of the 
box and you can move the box with dragging. That's one of the feature of 
absolutely positioned editor available even on Firefox.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to disable (hide) Gecko specific editing UI of HTML editor by default

2018-04-05 Thread Masayuki Nakano 

This incompatibility is pointed by W3C's Editing API WG:
https://github.com/w3c/editing/issues/171

Gecko has some specific editing UI of HTML editor.
1. Resiziers of , , absolute positioned elements.
2. Adding new table row/column from buttons.
3. Removing existing table row/column from buttons.
4. Grabber to move absolute positioned element.

Currently, all of those UIs are not implemented by the other browsers. 
However, they are available in Gecko by default.


Therefore, web app developers need to disable those features with:
document.execCommand("enableObjectResizing",
 false, false); // #1
document.execCommand("enableInlineTableEditing",
 false, false); // #2 and #3

So, if web apps don't call them, only Firefox users can modify  or 
 elements as unexpected for their developers.


Additionally, web apps cannot disable only #4.

So, for solving this incompatibility issue, we should:
* Disable those UI by default
* But allow to enable those UI for backward compatibility
* Add new command "enableAbsolutePositionEditing" command for allowing 
to enable #4


I'm working on this incompatibility issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1449564

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform