On 4/7/2018 12:39 AM, Ehsan Akhgari wrote:
On Thu, Apr 5, 2018 at 11:08 PM Masayuki Nakano <masay...@d-toybox.com
<mailto:masay...@d-toybox.com>> 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 again to remove the command once we decide to remove this UI based
on low usage. :-)
Indeed.
> * 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 that NAC frames get contructed (by adding an
alternative path to the "usual" way of doing that in Gecko), so
keeping the code in m-c would mean that we could at least keep testing
it and make sure that we don't break it in horrible ways in the
future... My main point was that it would be nice to get rid of this
alternate code path if we can make nobody depend on it.
Okay, but it seems that some features could be reimplemented simpler
with today's APIs. Currently, the are implemented with raw
mousedown/mousemove/mouseup events for handing D&D...
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
