Currently, this bug does not occur actually because nobody has not accessed
these command classes directly and they are registered only in command table
for HTML editor. However, once rewriting `nsHTMLDocument::ExecCommand()` with
these classes, its `IsCommandEnabled()` should return false if given editor
is `TextEditor`. The reason why we need this fix is, when we make
`ExecCommand()` call `IsCommandEnabled()` and it returns `true`, `ExecCommand()`
needs to call `DoCommand()`. Then, it throws exception if given editor is not
an `HTMLEditor` but the command class is only for `HTMLEditor`.
This patch adds new WPT for testing whether `document.execCommand()` works
with `<input>` and `<textarea>`. The behavior has not been standardized, but
Chromium handles some commands even in it. So, I write the expectations from
the point of view of web developers. (Chrome fails in "cut", "copy" and
"removeformat" cases.)
Differential Revision: https://phabricator.services.mozilla.com/D29473
--HG--
extra : moz-landing-system : lando
Due to the syntax limitation in failures.list, I cannot mark
multicol-rule-004.xht as fails with column-span enabled and success with
column-span disabled simultaneously. Luckily, we had another copy of it
in testing/web-platform/tests/css/css-multicol/multicol-rule-004.xht, We
can use it to test with column-span disabled for now.
Differential Revision: https://phabricator.services.mozilla.com/D29419
--HG--
extra : moz-landing-system : lando
The Content Security Policy tests were handling the smaller android preload
values that were #defined on Android by setting media.preload.default=2. Now
that we're detecting whether we're on cellular or not, and the android
emulators that our tests run on emulate a cellular connection, just setting
media.preload.default is no longer enough.
So set media.preload.default.cellular=2 in the CSP mochitests instead of
media.preload.default, to make the CSP mochitests pass in the Android
emulators.
Differential Revision: https://phabricator.services.mozilla.com/D29617
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
This allows Gecko to react to network link/status changes events as needed.
Differential Revision: https://phabricator.services.mozilla.com/D28942
--HG--
extra : moz-landing-system : lando
2019-05-03 02:43:22 +00:00
Eugen Sawin ext:(%2C%20Chris%20Pearce%20%3Ccpearce%40mozilla.com%3E)
Since we need to generate the full_task_set as a prereq to the target_task_set,
and since getting from full_task_set -> target_task_set is trivial.. we might
as well save both computed sets to the cache while we have them. This means users
that run:
$ ./mach try fuzzy
and then run:
$ ./mach try fuzzy --full
(or vice versa)
Will only incur task generation once. It also means that the 'watchman' trigger
will cache both taskgraphs.
Differential Revision: https://phabricator.services.mozilla.com/D29557
--HG--
extra : moz-landing-system : lando
This adds a 'watchman.json' file to /tools/tryselect and some documentation on
how to use it. Tl;dr, install watchman and then:
$ cd path/to/gecko
$ watchman -j < tools/tryselect/watchman.json
Differential Revision: https://phabricator.services.mozilla.com/D28771
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Bug 1547939 added a bunch of extra tests for three properties (background, mask,
and -webkit-mask). This made them time out more frequently in the Android
emulator.
Request a longer timeout to address this. Alternative is maybe just removing the
tests or such, I don't think they're of particularly great value.
Differential Revision: https://phabricator.services.mozilla.com/D29650
--HG--
extra : moz-landing-system : lando
Detect content process that already has connection to the RDD process
and don't attempt to relaunch or needlessly call
RDDProcessManager::CreateContentBridge. Calling CreateContentBridge
unnecessarily causes churn by recreating RemoteDecoderManagerParents.
Differential Revision: https://phabricator.services.mozilla.com/D29013
--HG--
extra : moz-landing-system : lando
