If copying selected password is allowed by `TextEditor`, we should allow to
drag it too because web apps usually request to input new password twice,
but if users used password generator, they may want to use drag and drop the
new password rather than copy and paste.
Differential Revision: https://phabricator.services.mozilla.com/D39279
--HG--
extra : moz-landing-system : lando
First, we need to make `nsCopySupport::FireClipboardEvent()` keep handling
`eCopy` and `eCut` event even in password field, only if `TextEditor` allows
them.
Then, we need to make `nsPlainTextSerializer::AppendText()` not expose
masked password for making users safer. Although `TextEditor` does not allow
`eCopy` nor `eCut` when selection is not in unmasked range. Fortunately,
retrieving masked and unmasked password from `nsTextFragment` has already
been implemented in `ContentEventHandler.cpp`. This patch moves it into
`EditorUtils` and makes `ContentEventHandler.cpp` and `nsPlaintextSerializer`
share it.
Differential Revision: https://phabricator.services.mozilla.com/D39000
--HG--
extra : moz-landing-system : lando
It does not make sense to copy masked password with mask characters.
Therefore, we should allow users to copy/cut in password fields only when
selected range is in unmasked range.
Note that for web-compat, copy/cut are always enabled in HTML/XHTML document
in content. Therefore this patch changes the behavior only in chrome's
password fields.
Additionally, only the test uses `nsIEditor.canDelete()`. Therefore, this
removes it and make the test use `nsIDocShell.isCommandEnabled()` instead.
Unfortunately, `nsIEditor.canCopy()` and `nsIEditor.canCut()` are used by
BlueGriffon, therefore, we cannot get rid of them for now.
Differential Revision: https://phabricator.services.mozilla.com/D38999
--HG--
rename : editor/libeditor/tests/test_bug1067255.html => editor/libeditor/tests/test_cut_copy_delete_command_enabled.html
extra : moz-landing-system : lando
Toolchain path for Windows version is `<NDK ROOT>/toolchains/llvm/prebuilt/windows-x86_64` etc, so it isn't '`winnt`.
So we has to replace `host.kernel.lower()` with `windows`.
Differential Revision: https://phabricator.services.mozilla.com/D39474
--HG--
extra : moz-landing-system : lando
When we use SVG layout, and transform-box is fill-box, the current
implementation makes the object not align with offset-path because there
may be an offset (SVG x and y values) between the anchor point and offset-path.
We have to tweak the anchor point to fix the alignment.
Differential Revision: https://phabricator.services.mozilla.com/D39419
--HG--
rename : testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box.html => testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box-001.html
rename : testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box.html => testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box-002.html
extra : moz-landing-system : lando
`layout.reflow.synthMouseMove` was added by Fennec/Maemo era (bug 657844) since this was low-end device. Since `layout.reflow.synthMouseMove` is false even if now, sampling rate of GeckoView's mouse event is still very sparse.
Since today is 2019, so we should change this to match sampling rate of mouse event with desktop.
Differential Revision: https://phabricator.services.mozilla.com/D39278
--HG--
extra : moz-landing-system : lando
`AddVarCache()` has a `bool aSkipAssignment` parameter. This patch removes that
parameter by splitting the function in two: `AddVarCache()` and
`AddVarCacheNoAssignment()`. (The former calls the latter.)
There are also tons of `Add*VarCache()` functions with `aSkipAssignment`
parameters that default to `false`. These defaults are never overridden, so
this patch removes the unnecessary arguments.
Differential Revision: https://phabricator.services.mozilla.com/D39433
--HG--
extra : moz-landing-system : lando
For some tasks, the workdir known to the decision task doesn't actually match
the workdir used in the task, which makes MOZ_FETCHES_DIR wrong when the
decision task derives it from the workdir.
On other tasks, MOZ_FETCHES_DIR is set to a relative directory, which
may work in some places where MOZ_FETCHES_DIR is used, but not in
others, that happen to be executed from a different directory.
To solve both problems, we set MOZ_FETCHES_DIR as a relative directory
everywhere, and we make run-task normalize it to an absolute path
before executing the task.
Differential Revision: https://phabricator.services.mozilla.com/D39152
--HG--
extra : moz-landing-system : lando
WebRender handling of position:sticky is buggy in the presence of zooming.
The fix for bug 1563717 exposes this bug in pinch-zoom-position-sticky.html.
Differential Revision: https://phabricator.services.mozilla.com/D39574
--HG--
extra : moz-landing-system : lando
The clip rect is derived from the composition bounds, which is in units that
are outside the resolution, but it's applied to the ScrollFrame item which is
inside the resolution.
Differential Revision: https://phabricator.services.mozilla.com/D37939
--HG--
extra : moz-landing-system : lando
It took me several searchs after having looked here for how to create windows
interactive tasks. Add a link to the documentation here as a hint.
Differential Revision: https://phabricator.services.mozilla.com/D39568
--HG--
extra : moz-landing-system : lando
This patch was generated automatically, by running the following command:
hg revert object-fit-contain-png-001e.html.ini -r 7018488ca120836111db492baf8fc852d0b699e3
...using the revision from just before the fuzzy annotation was replaced with a temporary expected-fail annotation in bug 1559276.
Depends on D39554
Differential Revision: https://phabricator.services.mozilla.com/D39564
--HG--
extra : moz-landing-system : lando