The spec change HTMLObjectElement tabIndex default to 0, but `test_object_plugin_nav.html` will fail due to HTMLObjectElement’s sequence focus and .focus() rely on default tabIndex. In this patch I separate the logic to not rely on default tabIndex for HTMLObjectElement's plugin type and align the spec.
Differential Revision: https://phabricator.services.mozilla.com/D50801
--HG--
extra : moz-landing-system : lando
Bug 917325 started using the `username` token.
Bug 1119063 started using the `new-password` token. This patch also adds support for `current-password` since it's the counterpart to `new-password` and we plan to use it as a signal eventually so want to encourage its use.
Differential Revision: https://phabricator.services.mozilla.com/D50351
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
I intend to enable still more mochitests in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D49524
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
This fixes several tests which snapshot remote windows under Fission. It also
changes some other arbitrary tests that don't use remote windows, which I
changed before I gave up on having an always-async API.
Differential Revision: https://phabricator.services.mozilla.com/D41630
--HG--
extra : rebase_source : 6203b7065f7651e6ed4a2695ff2bd92daec70634
The time input widget was missing a call to updateEditAttributes which was
caught by the test, which can be seen without this patch by going to:
data:text/html,<input type="time" disabled value="20:40">
Toggling the 'disabled' attribute back and forth fixes the rendering.
Differential Revision: https://phabricator.services.mozilla.com/D40503
This is what Chrome and Safari do.
See https://webcompat.com/issues/20701#issuecomment-436054739
So for exmaple, if there are two viewport meta tags like this;
<meta name="viewport" content="width=980">
<meta name="viewport" content="initial-scale=1,maximum-scale=1">
We will use "initial-scale=1,maximum-scale=1". Before this change we used to
use merged "width=980,initial-scale=1,maximum-scale=1".
Another example is to replace the content of a single viewport meta tag like this;
<meta id="viewport" name="viewport" content="width=device-width, initial-scale=1">
what will happen when this tag is replaced by below;
<meta id="viewport" name="viewport" content="width=1080">
We will use the replacing one (i.e. "width=1080"), before this change, we used
to use merged "width=1080,initial-scale=1".
As of this commit, we don't properly remove corresponding viewport meta data
when a) viewport meta tag is detached from document and b) `name` attribute is
changed from 'viewport'. These cases will be handled in subsequent commits.
Note that we no longer store invididual viewport meta data in Document::mHeaderData
so that nsIDOMWindowUtils.getDocumentMetadata doesn't work any more for the
invididual viewport meta data, but there is no use cases for them other than
two test cases which are removed in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D38922
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
This should be the minimal patch to fix the issue (should be safe for branches too).
Reusing an existing mouse/touch test for the crash testing.
Differential Revision: https://phabricator.services.mozilla.com/D34717
--HG--
extra : moz-landing-system : lando
This is done by sending a message over PBrowser and PBrowserBridge when the
event would fire to fire it in the correct process.
Differential Revision: https://phabricator.services.mozilla.com/D33083
--HG--
extra : moz-landing-system : lando
