`inputmode=none` means that OSK is closed.
`SetInputContext` doesn't call `DismissOnScreenKeyboard` directly since
`DismissOnScreenKeyboard` has no hack of Firefox VR.
Depends on D68316
Differential Revision: https://phabricator.services.mozilla.com/D68317
--HG--
extra : moz-landing-system : lando
As long as I test on my environment, bug 1226148 isn't fixed. Since native
message queue has high priority, Gecko may check whether focus is changed
before changing focus to another.
So we shouldn't use native message queue for this. It is better to use idle
queue instead.
Depends on D68315
Differential Revision: https://phabricator.services.mozilla.com/D68316
--HG--
extra : moz-landing-system : lando
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
--HG--
extra : moz-landing-system : lando
Current WHATWG spec is that `inputmode` attribute supports non-input element.
I would like to remove input element check for bug 142484 that is
contenteditable support.
Microsoft IME, Google IME and etc refer 1st input scope that they support, so
we will add both input scopes from `type` and `inputmode`.
Depends on D68313
Differential Revision: https://phabricator.services.mozilla.com/D68314
--HG--
extra : moz-landing-system : lando
Current WHATWG spec means that `numeric` is `IS_DIGITS` and `decimal` is
`IS_NUMBER`.
Depends on D68312
Differential Revision: https://phabricator.services.mozilla.com/D68313
--HG--
extra : moz-landing-system : lando
Gecko has duplicated code for input scope support, so I would like to clean up
this.
Differential Revision: https://phabricator.services.mozilla.com/D68312
--HG--
extra : moz-landing-system : lando
Are there any Rust crates outside mozilla-central that include or emit Mozilla C++ code that should be updated to use [[nodiscard]] instead of MOZ_MUST_USE?
Depends on D68751
Differential Revision: https://phabricator.services.mozilla.com/D69319
--HG--
extra : moz-landing-system : lando
Audit all the types related to app units [1] printed in
nsIFrame::List (and all the methods that override it), and use
ConvertToString to convert their printing format to CSS pixels if
needed.
In addition, add operator<< to BaseCoord so that it can cooperate with
mozilla::ToString, which is needed by ConvertToString.
[1] The types include nsRect, nsSize, nscoord, LogicalRect, and
LogicalSize.
Differential Revision: https://phabricator.services.mozilla.com/D69915
--HG--
extra : moz-landing-system : lando
Just waiting for the load event of the image doesn't even mean the image has been painted at all yet, but by the time MozReftestInvalidate fires the first frame should be guaranteed to have been painted.
Also, switch to using new img.decode api. img.decode will decode an animated version of the img, whereas drawing to a canvas will kick off a first frame only decode which the page can't use.
Differential Revision: https://phabricator.services.mozilla.com/D70104
--HG--
extra : moz-landing-system : lando
Loading just the image results in "theatre mode" display of the image (centered, dark background). But the test needs to be in an html document. We either changed how top level images were displayed or stopped using a style sheet in reftests that displayed images like this since the tests were last enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70103
--HG--
extra : moz-landing-system : lando
Previously, primitive dependency checking would invalidate a tile if
the spatial node index for a given primitive changed.
However, if a new display list is sent that changes the shape of
the spatial node tree this may cause unnecessary invalidations.
For example, a new display list that inserts a new spatial node at
the start of the tree could result in spatial node indices being
different, even though the values of the transforms was the same.
This patch changes the invalidation logic for spatial nodes to
compare the transforms by value, rather than index, meaning that
invalidations are avoided if the shape of the spatial tree has
changed, but the values are consistent.
Differential Revision: https://phabricator.services.mozilla.com/D69913
--HG--
extra : moz-landing-system : lando
Tests were added as a part of bug 1626471. Expectations that the tests fail
have been removed.
Differential Revision: https://phabricator.services.mozilla.com/D69605
--HG--
extra : moz-landing-system : lando
This also does a few remaining python 2 incompatible changes to
.configure files.
Differential Revision: https://phabricator.services.mozilla.com/D69538
--HG--
extra : moz-landing-system : lando
Many values we get out from configure are of types that look like
lists/tuples, that write_indented_repr will serialize as lists... but
only in python 2, because the alternative implementation for python 3
is not doing that. So sanitize first.
Differential Revision: https://phabricator.services.mozilla.com/D69949
--HG--
extra : moz-landing-system : lando
ConfigureSandbox._implied_options is a list of ReadOnlyNamespaces.
In python 3.5, ReadOnlyNamespaces end up with no guarantee in the order
of their __dict__. So when comparing
ReadOnlyNamespace(a=1, b=2)
and
ReadOnlyNamespace(a=3, b=4)
It's not guaranteed that the a's are compared before the b's.
In ConfigureSandbox._implied_options, some of those ReadOnlyNamespace
fields are SandboxDependsFunctions, which actually raise an error when
they're being compared, because we don't want that to happen in the
sandbox.
So when using python 3, configure would randomly fail when trying to
remove items from the ConfigureSandbox._implied_options list because
removing an item from a list scans the list to find the first element
that matches.
And ConfigureSandbox._implied_options needs to be ordered, which is why
it's currently a list.
So instead of removing by value, we create a new list with the remaining
values. But because the loop recurses, and needs the updated list, we
filter first.
Differential Revision: https://phabricator.services.mozilla.com/D69535
--HG--
extra : moz-landing-system : lando
Converts `ui.key.menuAccessKeyFocuses` to a static pref and removes `nsMenuBarListener::InitializeStatics()`. This pref sets to `true` in windows and linux, which may affect behavior in SeaMonkey and Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D69617
--HG--
extra : moz-landing-system : lando
Converts layout.framevisibility.numscrollportwidths and layout.framevisibility.numscrollportheights to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D69615
--HG--
extra : moz-landing-system : lando
Converts `layout.testing.overlay-scrollbars.always-visible` to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D69611
--HG--
extra : moz-landing-system : lando
Converts `dom.disable_beforeunload` and `dom.require_user_interaction_for_beforeunload` to static pref.
Differential Revision: https://phabricator.services.mozilla.com/D69600
--HG--
extra : moz-landing-system : lando
When the build is stalled for some random reason, and mach executed a
python subcommand (this may or may not be limited to python 3, I'm not
sure, and it doesn't really matter since it's a problem on python 3,
which matters most), the subcommand may not have actually sent its last
bits of output before the stall because its output is a pipe and in that
case python uses buffered outputs.
Now, when your build is completely stalled and you ctrl+C, you end up
without these bits of output, and in some cases, those bits of output
can contain actual information, like... tracebacks.
A real life example of this is bug 1624670 when running mach build or
mach configure with the patches from bug 1627163 applied, and configure
stalls without printing out the ValueError message at all.
Differential Revision: https://phabricator.services.mozilla.com/D69925
--HG--
extra : moz-landing-system : lando
By loading whatwg-url like this, we replace the worker global URL property
(among others), which means that code that uses `URL` and expects it to be the
version that is built into Firefox may not get what they expect.
Differential Revision: https://phabricator.services.mozilla.com/D69933
--HG--
extra : moz-landing-system : lando
Makoto Kato
Chris Peterson
Stefan Hindli
Ting-Yu Lin
Daosheng Mu
Timothy Nikkel
Emma Malysz
Glenn Watson
Timothy Gu
Randall E. Barker
Mike Hommey
Kristen Wright
Logan Smyth
David Major
Razvan Maries
Scott