Closed Bug 1452538 Opened 2 years ago Closed 2 years ago

Add telemetry probes for HTMLEditors which have shown Gecko build-in editing UIs and if they are operated

Categories

(Core :: DOM: Editor, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla62
Tracking Status
firefox61 --- wontfix
firefox62 --- fixed

People

(Reporter: masayuki, Assigned: masayuki)

References

Details

Attachments

(1 file)

Before landing bug 1449564, we should collect following usage data:

* How often HTMLEditor shows its build-in editing UI.
* How often the built-in editing UI operated by users actually.
Ehsan:

This is my first bug to add telemetry probes. Additionally, I'm not sure how to test them before landing and I'm not sure if the patch is correct. So, please be careful to review the patch.
FYI: I'm trying to get % of HTMLEditor instances which have had the editing UIs and whose UI are actually used.
Priority: -- → P3
Ehsan: ping, could you review it?
Flags: needinfo?(ehsan)
Hi Masayuki,

Sorry for the long delay to get back to you.

Your patch measures what you want to measure (the % of HTMLEditor instances which have had the editing UIs and whose UI are actually used).  But I wonder if this approach is actually going to be useful in practice.  I think to answer that you need to think about how you're going to use this data.  It's important to think about what this number is normalized against.  In the way that you've formulated the question, the baseline is the total number of HTMLEditor instances.  But if you think about it, that's a very hard thing to reason about, because we don't know anything about the total number of HTMLEditor instances that our users encounter.  For example, it could be that users hit HTMLEditor instances on 1% of all page loads, or on 5%, or 20%, or 0.05%, etc.  Assuming that you're planning to use this data in order to answer questions such as how commonly is one of these UIs used, so that we can decide whether we can go ahead and disable/remove them, it makes all of the difference in the world what this baseline number is.

Better ways to formulate questions like this could be: "What percentage of page loads see any HTMLEditor instantiation?", "What percentage of those instantiations see a given variant of this UI?", and "When a given variant of this UI is shown, how commonly does the user interact with it?".  The other thing to think about is whether only recording boolean histograms is sufficient.  For example, do we care if lots of people see this UI but only interact with it once or twice per page, versus the other case where the UI is shown very infrequently, but when it is shown the users tend to interact with it quite often (e.g. they tend to interact with it hundreds of times).  I suspect that you might want to record at least the data around how many times the UI is interacted with as a linear histogram to get a sense of how popular the UI is, but I'm mostly trying to ask these questions to give you a sense of the types of things that you might wonder about once we start to get the first batch of data in.  In general I've found that doing this kind of exercise can help to create more useful probes.

If you end up deciding to use something more sophisticated than boolean probes, you might find this tool helpful when designing your histograms: https://telemetry.mozilla.org/histogram-simulator

Last but not least, please note that in addition to a code review you also need a data collection review since you're adding new probes, please see https://wiki.mozilla.org/Firefox/Data_Collection for more details about that.
Flags: needinfo?(ehsan)
(I'm gonna wait for the review to give you a chance to think about the questions you'd like to ask, but if you think the current probes are sufficient, your current patch is mostly fine from a code review perspective.)
(In reply to :Ehsan Akhgari from comment #6)
> Sorry for the long delay to get back to you.

No problem, and thank you for thinking this issue deeply.

> Your patch measures what you want to measure (the % of HTMLEditor instances
> which have had the editing UIs and whose UI are actually used).  But I
> wonder if this approach is actually going to be useful in practice.  I think
> to answer that you need to think about how you're going to use this data. 
> It's important to think about what this number is normalized against.  In
> the way that you've formulated the question, the baseline is the total
> number of HTMLEditor instances.

Sure.

> But if you think about it, that's a very
> hard thing to reason about, because we don't know anything about the total
> number of HTMLEditor instances that our users encounter.  For example, it
> could be that users hit HTMLEditor instances on 1% of all page loads, or on
> 5%, or 20%, or 0.05%, etc.  Assuming that you're planning to use this data
> in order to answer questions such as how commonly is one of these UIs used,
> so that we can decide whether we can go ahead and disable/remove them, it
> makes all of the difference in the world what this baseline number is.

Absolutely. However, I think that it's enough to know the % of HTMLEditor instance because we cannot know users meet how may web apps which use HTMLEditor actually.  For example, some users may open Twitter only once per session, but some other users may repeat open/close only when they want to see. I believe that most important number is how may web apps use the feature, but I think that it's impossible to know from telemetry. Then, I think that the nearest meaning number is % of HTMLEditor instances.

> Better ways to formulate questions like this could be:
> "What percentage of page loads see any HTMLEditor instantiation?",

So, I'm still not sure if this is useful information for this issue since the rate does not affect to number of web apps which use HTMLEditor and our build-in UI.

> "What percentage of those instantiations see a given variant of this UI?",

Yeah, I think that this is the most important number.

> and "When a given variant of this UI is shown, how commonly does the user interact with it?".

And also this.

> The other thing to think about is whether only recording boolean histograms is
> sufficient.  For example, do we care if lots of people see this UI but only
> interact with it once or twice per page, versus the other case where the UI
> is shown very infrequently, but when it is shown the users tend to interact
> with it quite often (e.g. they tend to interact with it hundreds of times). 

Indeed, such difference is really important. Even if there is only one web app whose users use our built-in UI heavily, we *cannot remove* the feature anyway.  However, we must *be able to hide" the UI by default.

> I suspect that you might want to record at least the data around how many
> times the UI is interacted with as a linear histogram to get a sense of how
> popular the UI is,

Sure.

> but I'm mostly trying to ask these questions to give you
> a sense of the types of things that you might wonder about once we start to
> get the first batch of data in.  In general I've found that doing this kind
> of exercise can help to create more useful probes.
> 
> If you end up deciding to use something more sophisticated than boolean
> probes, you might find this tool helpful when designing your histograms:
> https://telemetry.mozilla.org/histogram-simulator

Thanks!

> Last but not least, please note that in addition to a code review you also
> need a data collection review since you're adding new probes, please see
> https://wiki.mozilla.org/Firefox/Data_Collection for more details about that.

Yeah, in my understanding, I need to get r+ first, then, need to request data collection review since until getting r+, collecting data is not fixed (like this). Is this correct?
User interaction count of resizer and grabber is incremented with mousedown event since mousemove event during drag is not useful due to too many count. Therefore, perhaps, we can say over 10 or 15 times per HTMLEditor is actually used by at least on one web app. So, max count 50 must be enough.
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) (away: 4/28 - 5/6) from comment #8)
> > But if you think about it, that's a very
> > hard thing to reason about, because we don't know anything about the total
> > number of HTMLEditor instances that our users encounter.  For example, it
> > could be that users hit HTMLEditor instances on 1% of all page loads, or on
> > 5%, or 20%, or 0.05%, etc.  Assuming that you're planning to use this data
> > in order to answer questions such as how commonly is one of these UIs used,
> > so that we can decide whether we can go ahead and disable/remove them, it
> > makes all of the difference in the world what this baseline number is.
> 
> Absolutely. However, I think that it's enough to know the % of HTMLEditor
> instance because we cannot know users meet how may web apps which use
> HTMLEditor actually.  For example, some users may open Twitter only once per
> session, but some other users may repeat open/close only when they want to
> see. I believe that most important number is how may web apps use the
> feature, but I think that it's impossible to know from telemetry. Then, I
> think that the nearest meaning number is % of HTMLEditor instances.
> 
> > Better ways to formulate questions like this could be:
> > "What percentage of page loads see any HTMLEditor instantiation?",
> 
> So, I'm still not sure if this is useful information for this issue since
> the rate does not affect to number of web apps which use HTMLEditor and our
> build-in UI.

Yes, ideally we would be able to normalize this against the number of web apps out there, but we can't know that due to privacy concerns, since otherwise we would have needed to build a giant dictionary mapping origins to counters indicating e.g. the number of instantiations of HTMLEditor, etc but that would reveal users' browsing history.   This is why we usually use things like the number of top-level page loads as a proxy for that ideal measure.

> > Last but not least, please note that in addition to a code review you also
> > need a data collection review since you're adding new probes, please see
> > https://wiki.mozilla.org/Firefox/Data_Collection for more details about that.
> 
> Yeah, in my understanding, I need to get r+ first, then, need to request
> data collection review since until getting r+, collecting data is not fixed
> (like this). Is this correct?

I'm fairly sure that you can ask for data collection review as soon as you have figured out what data you would like to collect and why, even if the coding questions around how to collect that data haven't all been resolved yet.  But it has been a while since I have personally asked for one of these reviews, perhaps things have changed.  :-)
Comment on attachment 8966250 [details]
Bug 1452538 - Add telemetry probes HTMLEditors which have shown Gecko build-in editing UIs and count of user interaction with them

https://reviewboard.mozilla.org/r/234952/#review246192

r=me assuming that this patch does what you want it to do, please see the comment below.

::: editor/libeditor/HTMLEditor.cpp:175
(Diff revision 2)
>  
>    RemoveEventListeners();
>  
>    HideAnonymousEditingUIs();
> +
> +  Telemetry::Accumulate(

FWIW, as I mentioned in the previous comment, I still think it's better if you normalize the main probes against something like the number of top-level page loads.  But it's up to you what you want to meausure so I'll review the current version.

One interesting implication of the way you have written your patch, which I'm not sure if it's intentional, is that your probes are actually normalized per documents that get _any_ HTMLEditor instantiation, not per HTMLEditor instantiation.

The reason is that (unless something has changed) we reused HTMLEditor instances after one gets created for a document, so for example if you set designMode to "on", "off" and back to "on" we should only create one HTMLEditor object.  When "off" is set, we should call HTMLEditor::PreDestroy() but not ~HTMLEditor(), and should only call ~HTMLEditor() when the document is being destroyed.

If you really intend for these probes to be per HTMLEditor instantiation, you should move this whole block to PreDestroy() and reset all of these members in case the HTMLEditor object gets reused again.
Attachment #8966250 - Flags: review?(ehsan) → review+
Comment on attachment 8966250 [details]
Bug 1452538 - Add telemetry probes HTMLEditors which have shown Gecko build-in editing UIs and count of user interaction with them

https://reviewboard.mozilla.org/r/234952/#review246192

> FWIW, as I mentioned in the previous comment, I still think it's better if you normalize the main probes against something like the number of top-level page loads.  But it's up to you what you want to meausure so I'll review the current version.
> 
> One interesting implication of the way you have written your patch, which I'm not sure if it's intentional, is that your probes are actually normalized per documents that get _any_ HTMLEditor instantiation, not per HTMLEditor instantiation.
> 
> The reason is that (unless something has changed) we reused HTMLEditor instances after one gets created for a document, so for example if you set designMode to "on", "off" and back to "on" we should only create one HTMLEditor object.  When "off" is set, we should call HTMLEditor::PreDestroy() but not ~HTMLEditor(), and should only call ~HTMLEditor() when the document is being destroyed.
> 
> If you really intend for these probes to be per HTMLEditor instantiation, you should move this whole block to PreDestroy() and reset all of these members in case the HTMLEditor object gets reused again.

> FWIW, as I mentioned in the previous comment, I still think it's better
> if you normalize the main probes against something like the number of
> top-level page loads.  But it's up to you what you want to meausure so
> I'll review the current version.

Thanks, I have another concern if we'd need to collect percentage of
instantiation in any page loads, we need to add a bool member or something
into nsIDocument or something. However, as far as I know, somebody don't
like to increase the instance size of such global objects.
E.g., using only 1 bit per bool member:
https://searchfox.org/mozilla-central/rev/68fdb6cf4f40bea1a1f6c07531ebf58fb8ab060b/dom/base/nsIDocument.h#3865

Is it allowed to add members for telemetry?

> One interesting implication of the way you have written your patch,
> which I'm not sure if it's intentional, is that your probes are actually
> normalized per documents that get any HTMLEditor instantiation, not per
> HTMLEditor instantiation.
> 
> The reason is that (unless something has changed) we reused HTMLEditor
> instances after one gets created for a document, so for example if you
> set designMode to "on", "off" and back to "on" we should only create one
> HTMLEditor object.  When "off" is set, we should call
> HTMLEditor::PreDestroy() but not ~HTMLEditor(), and should only call
> ~HTMLEditor() when the document is being destroyed.

Oh, I didn't realize that. However, my patch matches my intention. I assume
that switching designMode between "on" and "off" in a document does not
mean that it switches application. Even if there were such web apps, I
believe that it's rare case.  So, just counting with HTMLEditor instances
must be similar to what we want the data ideally (i.e., per web app).

Thank you very much for your polite explanation. I learned a lot from this!
Hello, François, could you data review for this bug? (Fortunately, there is r+'ed patch already.)

> What questions will you answer with this data?

Whether we can hide our specific (i.e., other browsers don't have) editing UI from contentediabe and designMode editor (or completely remove it from web).

The data will tell us:
* Percentage of HTMLEditor shows Gecko specific UIs, one is "resizers" of <img>, <table>, <div style="position:absolute">, etc,
"grabber" for moving <div style="position:absolute">, and "inline table editor" which can add/remove table rows and columns.
* Count of mousedown events of each Gecko specific UIs mentioned above. I.e., how much times the UIs are used by users when HTMLEditor shows them.

> Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?

The Gecko specific editing UIs are not implemented by Chrome, Safari nor Edge. Therefore, if web apps do not hide those UIs explicitly with JS, only Firefox users see the UIs. That may cause submitting unexpected result to the web apps.  Therefore, if such web apps are enough rare or user do not interact with the UIs actually, we can hide them by default safely or remove them from web completely. (bug 1449564)

> What alternative methods did you consider to answer these questions? Why were they not sufficient?

Only alternative idea is, just hiding the UIs by default only in Nightly and early Beta for collecting reports.  However, the conclusion with Ehsan, we should get more correct data to consider that since we may not get any reports but some users might be heavy user of the UIs.

> Can current instrumentation answer these questions?

I don't understand this question. If you mean that "Isn't there enough data in telemetry?", I'd say no.

> List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the Mozilla wiki.

I think that all 6 data are Category 2 “Interaction data”.

> Note that the data steward reviewing your request will characterize your data collection based on the highest (and most sensitive) category.
> Measurement Description 	Data Collection Category 	Tracking Bug #

Percentage of HTMLEditor        2                               bug 1452538 and bug 1449564.
instances which have shown
resizers.

Percentage of HTMLEditor        2                               bug 1452538 and bug 1449564.
instances which have shown
grabber of absolutely
positioned elements.

Percentage of HTMLEditor        2                               bug 1452538 and bug 1449564.
instances which have shown
inline table editor.

Count of mousedown event        2                               bug 1452538 and bug 1449564.
in resizers. (only counted
in HTMLEditor instances
which have shown resizers.)

Count of mousedown event        2                               bug 1452538 and bug 1449564.
in grabber. (only counted
in HTMLEditor instances
which have shown grabber.)

Count of mousedown event        2                               bug 1452538 and bug 1449564.
in inline table editor.
(only counted in HTMLEditor
instances which have shown
inline table editor.)

> How long will this data be collected? Choose one of the following:

~ Gecko 65. (needs a couple of cycles in Beta or Release)

> What populations will you measure?
> 
>   Which release channels?

Nightly, Beta and Release if possible (because there might be non-public web apps which targeted only Firefox).

>   Which countries?

Any.

>   Which locales?

Any.

>   Any other filters? Please describe in detail below.

No.

> If this data collection is default on, what is the opt-out mechanism for users?

out-out by default in release channel.

> Please provide a general description of how you will analyze this data.

If the percentage of the UIs are enough small, I'll hide the UI by default.  If the percentage is a few, but actual user interaction is almost 0, we can to it safely.

So, I'll check if the usage is near 0 or not.

>  Where do you intend to share the results of your analysis?

On bug 1449564 or its follow up bug if we'll land the patches which will hide the UI only in Nightly by default soon.
Flags: needinfo?(francois)
datareview+

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) (away: 4/28 - 5/6) from comment #15)

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes, in Histograms.json.

2) Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, telemetry setting.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**

Not permanent.

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **

Categories 1 and 2.

5) Is the data collection request for default-on or default-off?

Default-on, all channels.

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?

No.

7) Is the data collection covered by the existing Firefox privacy notice?

Yes.

8) Does there need to be a check-in in the future to determine whether to renew the data?

No, telemetry alerts are fine.
Flags: needinfo?(francois)
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/c44626b99de3
Add telemetry probes HTMLEditors which have shown Gecko build-in editing UIs and count of user interaction with them r=Ehsan
https://hg.mozilla.org/mozilla-central/rev/c44626b99de3
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Flags: qe-verify-
Results of Beta 62 users:

0.50% HTMLEditors of 210.37M samples (i.e., 1.05M samples) shew resizers of images, tables or absolute positioned elements. I believe that this is enough small number to *hide* the resizers by default.
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-09&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_RESIZERS&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-21&table=0&trim=0&use_submission_date=0

On the other hand, 0.13% of users of the 1.05M samples used resizers 17 times or more, especially, about 140 samples used resizers 40 times or more. So, perhaps, they *need* the feature so that we should not remove this feature.
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-09&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_RESIZERS_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-22&table=0&trim=0&use_submission_date=0

Next, 0.22% HTMLEditors of 210.37M samples (i.e., 454.93K samples) shew UI to edit table structure. I believe that this is enough smaall number to *hide* the UI by default.
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-09&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_INLINE_TABLE_EDITOR&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-21&table=0&trim=0&use_submission_date=0

On the other hand, 0.06% of users of the 41.56M samples used 17 times or more. The actual sample number may be enough small, 280, however, they might really require this UI. And perhaps, they need to pay not small cost to implement this UI by themselves. Therefore, I guess that we should keep this feature.
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-09&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_INLINE_TABLE_EDITOR_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-22&table=0&trim=0&use_submission_date=0

Finally, 0.43% HTMLEditors of 210.37M samples (i.e., 897.23K) shew UI to change position of absolute positioned elements. I believe that this is enough small number to *hide* the UI by default.
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-09&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_ABSOLUTE_POSITIONER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-21&table=0&trim=0&use_submission_date=0

On the other hand, only 10 users (not percent!) of the 897.23K used 17 times or more. The detail of the numbers are:

Times of dragged the grip        Number of users
1,	                         975
4,	                          74
6,	                          27
9,	                          15
12,	                          10
15,	                           2
17,	                           3
20,	                           2
28,	                           1
31,	                           1
45,	                           2
50,	                           1

Only few users dragged it. However, some users used ~10 times per HTMLEditor instance. I'm not sure whether we can remove this UI completely.  (Surprisingly, absolute positioned element grabber was shown more than table structure editing UI...)
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-09&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_ABSOLUTE_POSITIONER_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-22&table=0&trim=0&use_submission_date=0

Ehasan, how do you think?
Flags: needinfo?(ehsan)
Thanks for digging up the links and the data, Masayuki!

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #19)
> Results of Beta 62 users:
> 
> 0.50% HTMLEditors of 210.37M samples (i.e., 1.05M samples) shew resizers of
> images, tables or absolute positioned elements. I believe that this is
> enough small number to *hide* the resizers by default.
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_RESIZERS&mi
> n_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=sub
> missions&start_date=2018-06-21&table=0&trim=0&use_submission_date=0
> 
> On the other hand, 0.13% of users of the 1.05M samples used resizers 17
> times or more, especially, about 140 samples used resizers 40 times or more.
> So, perhaps, they *need* the feature so that we should not remove this
> feature.
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_RESIZERS_U
> SED_BY_USER&min_channel_version=null&processType=*&product=Firefox&sanitize=0
> &sort_keys=submissions&start_date=2018-06-
> 22&table=0&trim=0&use_submission_date=0

Hmm, what's the difference between hiding and removing?  Do you mean hiding the feature behind a preference but not removing it?

I think for all intents and purposes, for most of our users, once we hide a feature behind a preference it's gone.  So if we think a feature is useful for our users, we shouldn't hide it behind a preference, and if we don't think that, we should remove it.  (In other words, I don't think the in-between state of hidden features that are off by default makes much sense.)  The reason is that the only users who will be able to find it are those advanced users who may be able to dig up the technical articles which may or may not be written explaining how to change the preferences and whatnot.  Also those users will end up with a broken browser if we accidentally land code which breaks those off-by-default features...

> Next, 0.22% HTMLEditors of 210.37M samples (i.e., 454.93K samples) shew UI
> to edit table structure. I believe that this is enough smaall number to
> *hide* the UI by default.
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_INLINE_TABL
> E_EDITOR&min_channel_version=null&processType=*&product=Firefox&sanitize=0&so
> rt_keys=submissions&start_date=2018-06-
> 21&table=0&trim=0&use_submission_date=0
> 
> On the other hand, 0.06% of users of the 41.56M samples used 17 times or
> more. The actual sample number may be enough small, 280, however, they might
> really require this UI. And perhaps, they need to pay not small cost to
> implement this UI by themselves. Therefore, I guess that we should keep this
> feature.
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_INLINE_TAB
> LE_EDITOR_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox
> &sanitize=0&sort_keys=submissions&start_date=2018-06-
> 22&table=0&trim=0&use_submission_date=0
> 
> Finally, 0.43% HTMLEditors of 210.37M samples (i.e., 897.23K) shew UI to
> change position of absolute positioned elements. I believe that this is
> enough small number to *hide* the UI by default.
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_ABSOLUTE_PO
> SITIONER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&so
> rt_keys=submissions&start_date=2018-06-
> 21&table=0&trim=0&use_submission_date=0
> 
> On the other hand, only 10 users (not percent!) of the 897.23K used 17 times
> or more. The detail of the numbers are:
> 
> Times of dragged the grip        Number of users
> 1,	                         975
> 4,	                          74
> 6,	                          27
> 9,	                          15
> 12,	                          10
> 15,	                           2
> 17,	                           3
> 20,	                           2
> 28,	                           1
> 31,	                           1
> 45,	                           2
> 50,	                           1
> 
> Only few users dragged it. However, some users used ~10 times per HTMLEditor
> instance. I'm not sure whether we can remove this UI completely. 
> (Surprisingly, absolute positioned element grabber was shown more than table
> structure editing UI...)
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_ABSOLUTE_P
> OSITIONER_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox
> &sanitize=0&sort_keys=submissions&start_date=2018-06-
> 22&table=0&trim=0&use_submission_date=0
> 
> Ehasan, how do you think?

It's hard to say what's a good threshold for usage after which we can remove a feature...  None of these features seem super popular based on this data, so we should probably be able to remove them all.

However, here you're measuring three separate features, and the results are, we have a feature that is almost definitely unused (abspos dragger UI), and two others which are used in small amounts, but one (resize handles) is used almost twice as the other (table editing UI).  So I think that gives us a decent *order* in which to take action, and it gives us the opportunity to wait for feedback in between our actions.  In other words, for example, you could start by removing support for abspos draggers, and wait a cycle or two to see if there is any uproar on that.  And then move on to removing table editing UI, and after that, resize handles.  For the latter two, given that they both receive *some* usage, and it's hard to say with a high degree of confidence what that means, you might want to consider a gradual roll-out model for disabling them, which allows you to disable the feature gradually for a larger and larger portion of users on the release channel and in each stage wait for feedback and potentially change course if something unpredicted goes wrong.  I think RemoteSettings (https://wiki.mozilla.org/Firefox/RemoteSettings) is the right tool for doing that these days, please ping the folks working on that for more info (I don't have any personal experience using it myself unfortunately).

Another suggestion that I have is to wait for some telemetry data from the release channel as well before taking any action, in case the release channel population happens to browse a different enough set of sites that would make a difference here in some way.

Last but not least, I'm not sure how you're going to deal with comm-central consumers.  Thunderbird might want these features for the composition UI.  BlueGriffon almost certainly would want to retain all of these features...

Hope this is helpful!
Flags: needinfo?(ehsan)
(In reply to :Ehsan Akhgari from comment #20)
> Thanks for digging up the links and the data, Masayuki!
> 
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #19)
> > Results of Beta 62 users:
> > 
> > 0.50% HTMLEditors of 210.37M samples (i.e., 1.05M samples) shew resizers of
> > images, tables or absolute positioned elements. I believe that this is
> > enough small number to *hide* the resizers by default.
> > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_RESIZERS&mi
> > n_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=sub
> > missions&start_date=2018-06-21&table=0&trim=0&use_submission_date=0
> > 
> > On the other hand, 0.13% of users of the 1.05M samples used resizers 17
> > times or more, especially, about 140 samples used resizers 40 times or more.
> > So, perhaps, they *need* the feature so that we should not remove this
> > feature.
> > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_RESIZERS_U
> > SED_BY_USER&min_channel_version=null&processType=*&product=Firefox&sanitize=0
> > &sort_keys=submissions&start_date=2018-06-
> > 22&table=0&trim=0&use_submission_date=0
> 
> Hmm, what's the difference between hiding and removing?  Do you mean hiding
> the feature behind a preference but not removing it?

"Hiding" means that the UI id now enabled by default, but can be enabled by web apps using execCommand.

"Removing" means what you think is, i.e., behind pref or complete removed from mozilla-central (but comm-central might need all or some of them, though).

> I think for all intents and purposes, for most of our users, once we hide a
> feature behind a preference it's gone.  So if we think a feature is useful
> for our users, we shouldn't hide it behind a preference, and if we don't
> think that, we should remove it.  (In other words, I don't think the
> in-between state of hidden features that are off by default makes much
> sense.)  The reason is that the only users who will be able to find it are
> those advanced users who may be able to dig up the technical articles which
> may or may not be written explaining how to change the preferences and
> whatnot.  Also those users will end up with a broken browser if we
> accidentally land code which breaks those off-by-default features...

Yeah, I don't think that we should keep them only for a few users since the implementation is too big and complicated for that. On the other hand, those features might be used by Thunderbird or mail client and/or composer of SeaMonkey (and Bluegriffon?). So, I believe that if nobody uses those features and we can make them behind prefs, we should remove it. However, at least for now, we should decide whether each feature requires execCommand call of web apps explicitly since other browsers do not have those features. Then, we can re collect telemetry without users who touched the UI accidentally.

> > Next, 0.22% HTMLEditors of 210.37M samples (i.e., 454.93K samples) shew UI
> > to edit table structure. I believe that this is enough smaall number to
> > *hide* the UI by default.
> > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_INLINE_TABL
> > E_EDITOR&min_channel_version=null&processType=*&product=Firefox&sanitize=0&so
> > rt_keys=submissions&start_date=2018-06-
> > 21&table=0&trim=0&use_submission_date=0
> > 
> > On the other hand, 0.06% of users of the 41.56M samples used 17 times or
> > more. The actual sample number may be enough small, 280, however, they might
> > really require this UI. And perhaps, they need to pay not small cost to
> > implement this UI by themselves. Therefore, I guess that we should keep this
> > feature.
> > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_INLINE_TAB
> > LE_EDITOR_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox
> > &sanitize=0&sort_keys=submissions&start_date=2018-06-
> > 22&table=0&trim=0&use_submission_date=0
> > 
> > Finally, 0.43% HTMLEditors of 210.37M samples (i.e., 897.23K) shew UI to
> > change position of absolute positioned elements. I believe that this is
> > enough small number to *hide* the UI by default.
> > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_ABSOLUTE_PO
> > SITIONER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&so
> > rt_keys=submissions&start_date=2018-06-
> > 21&table=0&trim=0&use_submission_date=0
> > 
> > On the other hand, only 10 users (not percent!) of the 897.23K used 17 times
> > or more. The detail of the numbers are:
> > 
> > Times of dragged the grip        Number of users
> > 1,	                         975
> > 4,	                          74
> > 6,	                          27
> > 9,	                          15
> > 12,	                          10
> > 15,	                           2
> > 17,	                           3
> > 20,	                           2
> > 28,	                           1
> > 31,	                           1
> > 45,	                           2
> > 50,	                           1
> > 
> > Only few users dragged it. However, some users used ~10 times per HTMLEditor
> > instance. I'm not sure whether we can remove this UI completely. 
> > (Surprisingly, absolute positioned element grabber was shown more than table
> > structure editing UI...)
> > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_ABSOLUTE_P
> > OSITIONER_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox
> > &sanitize=0&sort_keys=submissions&start_date=2018-06-
> > 22&table=0&trim=0&use_submission_date=0
> > 
> > Ehasan, how do you think?
> 
> It's hard to say what's a good threshold for usage after which we can remove
> a feature...  None of these features seem super popular based on this data,
> so we should probably be able to remove them all.
> 
> However, here you're measuring three separate features, and the results are,
> we have a feature that is almost definitely unused (abspos dragger UI), and
> two others which are used in small amounts, but one (resize handles) is used
> almost twice as the other (table editing UI).  So I think that gives us a
> decent *order* in which to take action, and it gives us the opportunity to
> wait for feedback in between our actions.  In other words, for example, you
> could start by removing support for abspos draggers, and wait a cycle or two
> to see if there is any uproar on that.  And then move on to removing table
> editing UI, and after that, resize handles.  For the latter two, given that
> they both receive *some* usage, and it's hard to say with a high degree of
> confidence what that means, you might want to consider a gradual roll-out
> model for disabling them, which allows you to disable the feature gradually
> for a larger and larger portion of users on the release channel and in each
> stage wait for feedback and potentially change course if something
> unpredicted goes wrong.  I think RemoteSettings
> (https://wiki.mozilla.org/Firefox/RemoteSettings) is the right tool for
> doing that these days, please ping the folks working on that for more info
> (I don't have any personal experience using it myself unfortunately).
> 
> Another suggestion that I have is to wait for some telemetry data from the
> release channel as well before taking any action, in case the release
> channel population happens to browse a different enough set of sites that
> would make a difference here in some way.

Thanks. Okay, I think that we can "hide" those features only in early Beta and Nightly now. Perhaps, they should be enabled with *both* execCommand (by web apps) and new prefs (by users). Then, testers can avoid their inconvenience temporarily.

> Last but not least, I'm not sure how you're going to deal with comm-central
> consumers.  Thunderbird might want these features for the composition UI. 
> BlueGriffon almost certainly would want to retain all of these features...

Current editor policy is, if there is no alternative ways, we keep supporting any existing features. However, we should not use such features as far as possible. E.g., we still support nsIEditActionListener only for our findbar and some addons for Thunderbird. However, unless findbar is opened, editor won't call any methods of the listener since our internal classes have already stopped using the interface. So, in other words, editor respects run-time cost (for Quantum Flow), but still does not respect binary size nor maintenance code for keeping existing and used features.

> Hope this is helpful!

Yes, your advice always helps me!
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21)
> (In reply to :Ehsan Akhgari from comment #20)
> > Thanks for digging up the links and the data, Masayuki!
> > 
> > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #19)
> > > Results of Beta 62 users:
> > > 
> > > 0.50% HTMLEditors of 210.37M samples (i.e., 1.05M samples) shew resizers of
> > > images, tables or absolute positioned elements. I believe that this is
> > > enough small number to *hide* the resizers by default.
> > > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_RESIZERS&mi
> > > n_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=sub
> > > missions&start_date=2018-06-21&table=0&trim=0&use_submission_date=0
> > > 
> > > On the other hand, 0.13% of users of the 1.05M samples used resizers 17
> > > times or more, especially, about 140 samples used resizers 40 times or more.
> > > So, perhaps, they *need* the feature so that we should not remove this
> > > feature.
> > > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_RESIZERS_U
> > > SED_BY_USER&min_channel_version=null&processType=*&product=Firefox&sanitize=0
> > > &sort_keys=submissions&start_date=2018-06-
> > > 22&table=0&trim=0&use_submission_date=0
> > 
> > Hmm, what's the difference between hiding and removing?  Do you mean hiding
> > the feature behind a preference but not removing it?
> 
> "Hiding" means that the UI id now enabled by default, but can be enabled by
> web apps using execCommand.

I see what you mean...  I now remember that you had suggested this on the dev-platform thread.

I guess I'm in general not in favour of adding new execCommand commands that aren't going to be interoperable with other browsers.  I expect that no other browser vendors are planning to implement such commands that enable these kinds of UI elements.  And of course, web pages would need to opt in to using these commands, and in many practical scenarios that would mean a page upgrading to a new version of a library which adds support for these Firefox-only commands.  This feels like a stretch to me, to be honest.  But I suppose that if we do add these commands we can at least add some telemetry to monitor their usage, and remove them at some point if they never receive any adoption...

> "Removing" means what you think is, i.e., behind pref or complete removed
> from mozilla-central (but comm-central might need all or some of them,
> though).
> 
> > I think for all intents and purposes, for most of our users, once we hide a
> > feature behind a preference it's gone.  So if we think a feature is useful
> > for our users, we shouldn't hide it behind a preference, and if we don't
> > think that, we should remove it.  (In other words, I don't think the
> > in-between state of hidden features that are off by default makes much
> > sense.)  The reason is that the only users who will be able to find it are
> > those advanced users who may be able to dig up the technical articles which
> > may or may not be written explaining how to change the preferences and
> > whatnot.  Also those users will end up with a broken browser if we
> > accidentally land code which breaks those off-by-default features...
> 
> Yeah, I don't think that we should keep them only for a few users since the
> implementation is too big and complicated for that. On the other hand, those
> features might be used by Thunderbird or mail client and/or composer of
> SeaMonkey (and Bluegriffon?). So, I believe that if nobody uses those
> features and we can make them behind prefs, we should remove it. However, at
> least for now, we should decide whether each feature requires execCommand
> call of web apps explicitly since other browsers do not have those features.
> Then, we can re collect telemetry without users who touched the UI
> accidentally.
> 
> > > Next, 0.22% HTMLEditors of 210.37M samples (i.e., 454.93K samples) shew UI
> > > to edit table structure. I believe that this is enough smaall number to
> > > *hide* the UI by default.
> > > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_INLINE_TABL
> > > E_EDITOR&min_channel_version=null&processType=*&product=Firefox&sanitize=0&so
> > > rt_keys=submissions&start_date=2018-06-
> > > 21&table=0&trim=0&use_submission_date=0
> > > 
> > > On the other hand, 0.06% of users of the 41.56M samples used 17 times or
> > > more. The actual sample number may be enough small, 280, however, they might
> > > really require this UI. And perhaps, they need to pay not small cost to
> > > implement this UI by themselves. Therefore, I guess that we should keep this
> > > feature.
> > > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_INLINE_TAB
> > > LE_EDITOR_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox
> > > &sanitize=0&sort_keys=submissions&start_date=2018-06-
> > > 22&table=0&trim=0&use_submission_date=0
> > > 
> > > Finally, 0.43% HTMLEditors of 210.37M samples (i.e., 897.23K) shew UI to
> > > change position of absolute positioned elements. I believe that this is
> > > enough small number to *hide* the UI by default.
> > > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WITH_ABSOLUTE_PO
> > > SITIONER&min_channel_version=null&processType=*&product=Firefox&sanitize=0&so
> > > rt_keys=submissions&start_date=2018-06-
> > > 21&table=0&trim=0&use_submission_date=0
> > > 
> > > On the other hand, only 10 users (not percent!) of the 897.23K used 17 times
> > > or more. The detail of the numbers are:
> > > 
> > > Times of dragged the grip        Number of users
> > > 1,	                         975
> > > 4,	                          74
> > > 6,	                          27
> > > 9,	                          15
> > > 12,	                          10
> > > 15,	                           2
> > > 17,	                           3
> > > 20,	                           2
> > > 28,	                           1
> > > 31,	                           1
> > > 45,	                           2
> > > 50,	                           1
> > > 
> > > Only few users dragged it. However, some users used ~10 times per HTMLEditor
> > > instance. I'm not sure whether we can remove this UI completely. 
> > > (Surprisingly, absolute positioned element grabber was shown more than table
> > > structure editing UI...)
> > > https://telemetry.mozilla.org/new-pipeline/dist.html#!
> > > cumulative=0&end_date=2018-08-09&keys=__none__!__none__!
> > > __none__&max_channel_version=beta%252F62&measure=HTMLEDITORS_WHOSE_ABSOLUTE_P
> > > OSITIONER_USED_BY_USER&min_channel_version=null&processType=*&product=Firefox
> > > &sanitize=0&sort_keys=submissions&start_date=2018-06-
> > > 22&table=0&trim=0&use_submission_date=0
> > > 
> > > Ehasan, how do you think?
> > 
> > It's hard to say what's a good threshold for usage after which we can remove
> > a feature...  None of these features seem super popular based on this data,
> > so we should probably be able to remove them all.
> > 
> > However, here you're measuring three separate features, and the results are,
> > we have a feature that is almost definitely unused (abspos dragger UI), and
> > two others which are used in small amounts, but one (resize handles) is used
> > almost twice as the other (table editing UI).  So I think that gives us a
> > decent *order* in which to take action, and it gives us the opportunity to
> > wait for feedback in between our actions.  In other words, for example, you
> > could start by removing support for abspos draggers, and wait a cycle or two
> > to see if there is any uproar on that.  And then move on to removing table
> > editing UI, and after that, resize handles.  For the latter two, given that
> > they both receive *some* usage, and it's hard to say with a high degree of
> > confidence what that means, you might want to consider a gradual roll-out
> > model for disabling them, which allows you to disable the feature gradually
> > for a larger and larger portion of users on the release channel and in each
> > stage wait for feedback and potentially change course if something
> > unpredicted goes wrong.  I think RemoteSettings
> > (https://wiki.mozilla.org/Firefox/RemoteSettings) is the right tool for
> > doing that these days, please ping the folks working on that for more info
> > (I don't have any personal experience using it myself unfortunately).
> > 
> > Another suggestion that I have is to wait for some telemetry data from the
> > release channel as well before taking any action, in case the release
> > channel population happens to browse a different enough set of sites that
> > would make a difference here in some way.
> 
> Thanks. Okay, I think that we can "hide" those features only in early Beta
> and Nightly now. Perhaps, they should be enabled with *both* execCommand (by
> web apps) and new prefs (by users). Then, testers can avoid their
> inconvenience temporarily.

Another possible approach that you can consider, if you choose to be more aggressive, is to *disable* these features on Nightly and early Beta for a few cycles and wait to see if you hear any complaints about the features going away.  It's hard to say whether it was OK to kill a feature by lack of people complaining, but on the other hand you might find out that people actually notice this removal and complain in ways that wasn't obvious from telemetry data...

Best of luck on the rest of this journey.  :-)
(In reply to :Ehsan Akhgari from comment #22)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21)
> > (In reply to :Ehsan Akhgari from comment #20)
> > > Thanks for digging up the links and the data, Masayuki!
> > > 
> > > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #19)
> > > Hmm, what's the difference between hiding and removing?  Do you mean hiding
> > > the feature behind a preference but not removing it?
> > 
> > "Hiding" means that the UI id now enabled by default, but can be enabled by
> > web apps using execCommand.
> 
> I see what you mean...  I now remember that you had suggested this on the
> dev-platform thread.
> 
> I guess I'm in general not in favour of adding new execCommand commands that
> aren't going to be interoperable with other browsers.

Of course, me too.

> I expect that no
> other browser vendors are planning to implement such commands that enable
> these kinds of UI elements.  And of course, web pages would need to opt in
> to using these commands, and in many practical scenarios that would mean a
> page upgrading to a new version of a library which adds support for these
> Firefox-only commands.  This feels like a stretch to me, to be honest.  But
> I suppose that if we do add these commands we can at least add some
> telemetry to monitor their usage, and remove them at some point if they
> never receive any adoption...

Good point. I'll add telemetry for the usage as opt-in.
(FYI: Adding only one command. For resizing and inline-table-editing, we've already have the specific commands to disable them. And they are used for disabling the UIs on Gecko.)

> > > Another suggestion that I have is to wait for some telemetry data from the
> > > release channel as well before taking any action, in case the release
> > > channel population happens to browse a different enough set of sites that
> > > would make a difference here in some way.
> > 
> > Thanks. Okay, I think that we can "hide" those features only in early Beta
> > and Nightly now. Perhaps, they should be enabled with *both* execCommand (by
> > web apps) and new prefs (by users). Then, testers can avoid their
> > inconvenience temporarily.
> 
> Another possible approach that you can consider, if you choose to be more
> aggressive, is to *disable* these features on Nightly and early Beta for a
> few cycles and wait to see if you hear any complaints about the features
> going away.  It's hard to say whether it was OK to kill a feature by lack of
> people complaining, but on the other hand you might find out that people
> actually notice this removal and complain in ways that wasn't obvious from
> telemetry data...

Hmm, it sounds like too aggressive to me. I agree with get rid of them is the best. However, in other web-compat bugs, I learned that even for Nightly users, we should give any inconvenience as far as possible for preventing losing valuable our testers. Therefore, I'll add a pref to enable them forcibly by the testers.

Anyway, I'll collect new telemetry data of the commands, and then, we should be back around here for deciding whether we can get rid of them completely from the web.

> Best of luck on the rest of this journey.  :-)

Thank you very much!
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #23)
> (FYI: Adding only one command. For resizing and inline-table-editing, we've
> already have the specific commands to disable them. And they are used for
> disabling the UIs on Gecko.)

It would be very interesting to see whether those commands are being used in the wild, and if so how commonly...

> > > > Another suggestion that I have is to wait for some telemetry data from the
> > > > release channel as well before taking any action, in case the release
> > > > channel population happens to browse a different enough set of sites that
> > > > would make a difference here in some way.
> > > 
> > > Thanks. Okay, I think that we can "hide" those features only in early Beta
> > > and Nightly now. Perhaps, they should be enabled with *both* execCommand (by
> > > web apps) and new prefs (by users). Then, testers can avoid their
> > > inconvenience temporarily.
> > 
> > Another possible approach that you can consider, if you choose to be more
> > aggressive, is to *disable* these features on Nightly and early Beta for a
> > few cycles and wait to see if you hear any complaints about the features
> > going away.  It's hard to say whether it was OK to kill a feature by lack of
> > people complaining, but on the other hand you might find out that people
> > actually notice this removal and complain in ways that wasn't obvious from
> > telemetry data...
> 
> Hmm, it sounds like too aggressive to me. I agree with get rid of them is
> the best. However, in other web-compat bugs, I learned that even for Nightly
> users, we should give any inconvenience as far as possible for preventing
> losing valuable our testers. Therefore, I'll add a pref to enable them
> forcibly by the testers.

Fair enough!
(In reply to :Ehsan Akhgari from comment #24)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #23)
> > (FYI: Adding only one command. For resizing and inline-table-editing, we've
> > already have the specific commands to disable them. And they are used for
> > disabling the UIs on Gecko.)
> 
> It would be very interesting to see whether those commands are being used in
> the wild, and if so how commonly...

As for the disabling commands: As things are now, richtext editing on the web in production usecases takes place in specialized JavaScript programs that manage one or several contenteditable elements. These editors are major projects that have a decade or so of development put into them, and there are not that many of them. The editors are needed to gloss over the various bugs in this space and the differences between browser implementations. All those editors we could find included the commands to disable the controls specifically for Firefox. In many cases this is the only or one of very few uses of execCommand.

> 
> > > > > Another suggestion that I have is to wait for some telemetry data from the
> > > > > release channel as well before taking any action, in case the release
> > > > > channel population happens to browse a different enough set of sites that
> > > > > would make a difference here in some way.
> > > > 
> > > > Thanks. Okay, I think that we can "hide" those features only in early Beta
> > > > and Nightly now. Perhaps, they should be enabled with *both* execCommand (by
> > > > web apps) and new prefs (by users). Then, testers can avoid their
> > > > inconvenience temporarily.
> > > 
> > > Another possible approach that you can consider, if you choose to be more
> > > aggressive, is to *disable* these features on Nightly and early Beta for a
> > > few cycles and wait to see if you hear any complaints about the features
> > > going away.  It's hard to say whether it was OK to kill a feature by lack of
> > > people complaining, but on the other hand you might find out that people
> > > actually notice this removal and complain in ways that wasn't obvious from
> > > telemetry data...
> > 
> > Hmm, it sounds like too aggressive to me. I agree with get rid of them is
> > the best. However, in other web-compat bugs, I learned that even for Nightly
> > users, we should give any inconvenience as far as possible for preventing
> > losing valuable our testers. Therefore, I'll add a pref to enable them
> > forcibly by the testers.
> 
> Fair enough!
(In reply to johanneswilm from comment #25)
> (In reply to :Ehsan Akhgari from comment #24)
> > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #23)
> > > (FYI: Adding only one command. For resizing and inline-table-editing, we've
> > > already have the specific commands to disable them. And they are used for
> > > disabling the UIs on Gecko.)
> > 
> > It would be very interesting to see whether those commands are being used in
> > the wild, and if so how commonly...
> 
> As for the disabling commands: As things are now, richtext editing on the
> web in production usecases takes place in specialized JavaScript programs
> that manage one or several contenteditable elements. These editors are major
> projects that have a decade or so of development put into them, and there
> are not that many of them. The editors are needed to gloss over the various
> bugs in this space and the differences between browser implementations. All
> those editors we could find included the commands to disable the controls
> specifically for Firefox. In many cases this is the only or one of very few
> uses of execCommand.

Yes, thanks for raising this excellent point!  The disable commands should probably be quite popular due to this reason.

(This indeed matches my experience over the years looking at such frameworks and hearing from folks developing them, BTW.)
You need to log in before you can comment on or make changes to this bug.