An error crept in, resulting in:
```
[task ...] InterpreterError: InterpreterError: infix: [..] expects integer [..] integer
```
At some point, `suite` became a string name and not an object with a
string `name` member. However, in the interim, the diversity of
`command` structures has made the template approach untenable.
Therefore, this commit converts `GeckoProfile` to a `TryConfig`. The
existing test clearly wasn't helpful, and it doesn't really map to a
`TryConfig` test, so it was removed.
Differential Revision: https://phabricator.services.mozilla.com/D41603
--HG--
extra : moz-landing-system : lando
Re-enable skipped webRTC tests on Mac which were disabled due to the macOS 10.14 permission prompts causing timeouts.
Don't trigger OS camera and microphone permission prompts for fake devices (used for tests).
Differential Revision: https://phabricator.services.mozilla.com/D46893
--HG--
extra : moz-landing-system : lando
Gecko was trying to pass formatter options in by default, which
doesn't work if the user overrides the formatter. Instead pass in the
default options explicitly using the designed mechanism, which
previously wasn't exposed in wpt.
Differential Revision: https://phabricator.services.mozilla.com/D47117
--HG--
extra : moz-landing-system : lando
A bunch of loop-detection, etc, complexity goes away because mixins are not
interfaces and the mixin syntax does not allow various things we had to guard
against in terms of maplikes and whatnot.
Differential Revision: https://phabricator.services.mozilla.com/D46524
--HG--
extra : moz-landing-system : lando
D46944 / bug 1583534 is what fixes the root cause of bug 1528052 by not
having the first call to ResizeReflow have a wrong old size of 0x0.
This removes the code that bug introduces to suppress resize events, which
fixes this bug. I think our behavior now is pretty sane.
In particular, consider the test-case:
<!doctype html>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<a href="" target="_blank">Open me in a separate tab</a>
<pre id="log"></pre>
<script>
// This shouldn't be needed, but otherwise Fenix doesn't show the tooltip on
// longpress...
document.querySelector("a").href = location.href;
function logSize() {
log.innerText += window.innerWidth + "x" + window.innerHeight + "\n";
}
logSize();
onresize = logSize;
</script>
(Hosted at https://crisal.io/tmp/gecko-mobile-resize.html for convenience)
Right now on trunk, when you click the link from GVE or Fenix, we're only
getting an initial size of 0x0 (which is not great, btw), and only after first
paint we get the real device size, but content doesn't get a resize event.
This is obviously wrong, every time the layout viewport changes we should fire
resize events.
Pages that get opened in new tabs and get refreshed when resized may get an
extra reload with this approach, but this seems not avoidable unless widget sets
the viewport size right in advance (which from discussion with snorp and agi
doesn't seem possible in the general case).
What used to happen is that we were triggering a redundant resize reflow from
the initial paint which didn't update the layout viewport (because the content
viewer and co had the right viewport from the previous navigation).
Now that we optimize those away, I think our behavior should be correct.
Differential Revision: https://phabricator.services.mozilla.com/D46956
--HG--
extra : moz-landing-system : lando
mSuspendedForDiversion is for the same purpose.
All function involved happened in the same thread.
Differential Revision: https://phabricator.services.mozilla.com/D47124
--HG--
extra : moz-landing-system : lando
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
--HG--
extra : moz-landing-system : lando
Otherwise, what happens in documents like the webconsole is the theme file gets loaded before
global.css, which isn't the intended behavior and makes overriding the styles from global.css
more difficult. As an example, some buttons in the webconsole became stretched after Bug 1581914
changed some default styling in global.css. This patch restores the correct behavior by loading
the theme afer global.css.
global.css is currently loaded in devtools in docs that explicitly use XUL elements (such as storage inspector
and style editor), and in docs that need to be supported as top level windows (webconsole, toolbox, and
browser toolbox). Unless if we change how things like panels and context menus are styled, the latter
group will continue to need to load global.css even as XUL/XBL usage goes away (since they are styled
with global.css).
Differential Revision: https://phabricator.services.mozilla.com/D46530
--HG--
extra : moz-landing-system : lando
Skip test on fission to avoid frequent intermittent failures. Although already
marked as failing, the way this test fails still causes task failures unless
the test is skipped.
Differential Revision: https://phabricator.services.mozilla.com/D47133
--HG--
extra : moz-landing-system : lando
Right now testOnTelemetryReceived assumes that only the test histograms will
fire during the test. This works because only the test histograms are enabled
for streaming telemetry and will break as soon as some other histogram is
enabled.
Instead of relying on this fact we just wait for the test histogram to fire and
ignore all the other unrelated ones.
Differential Revision: https://phabricator.services.mozilla.com/D47015
--HG--
extra : moz-landing-system : lando
In bug 1565689, we have implemented new an audio focus management, which allows us to address audio competition even if those audio happens on different processes.
We can try to enable this new mechanism on Android Nightly first, where we have enabled managing audio competition by default.
Differential Revision: https://phabricator.services.mozilla.com/D46636
--HG--
extra : moz-landing-system : lando
Just this._update() is not enough to update everything that changing the theme
implies. Instead, use the observer mechanism so all the pieces of code involved
update properly.
Differential Revision: https://phabricator.services.mozilla.com/D45926
--HG--
extra : moz-landing-system : lando
Same origin native functions called with a compatible cross-origin `this`
object are meant to apply the same security checks as if a property getter for
the method had been called on the `this` object directly. Firefox has some
tests for this behavior, but the web platform test suite does not.
This patch adds comprehensive tests for all getters/setters/methods on Window
and Location objects for both the allowed and forbidden cases.
Differential Revision: https://phabricator.services.mozilla.com/D46736
--HG--
extra : moz-landing-system : lando
Cross-origin objects are supposed to have null prototypes, and throw when
attempting to set the prototype to any value other than null. Ordinary
cross-origin objects handle this correctly. RemoteObjectProxy has hooks which
are meant to give them the same behavior, but which are never actually
triggered, because the proxy objects are missing the required lazy prototype
flags.
Simply using the built-in prototype slot and setting it to immutable triggers
the desired behavior with much less implementation overhead.
Differential Revision: https://phabricator.services.mozilla.com/D46735
--HG--
extra : moz-landing-system : lando
Object.hasOwnProperty called on a cross-origin object needs to return true for
any property returned by its property enumerator or get hook, and throw a
security error for anything else. Ordinary cross-origin objects currently
behave correctly, but RemoteObjectProxy objects return false for indexed
frame getters, and never throw security exceptions for inaccessible
properties.
This patch fixes both of those issues by removing the `hasOwn` hook and
falling back to the BaseProxyHandler implementation, which defers to the
`getOwnPropertyDescriptor` hook. This is slightly more expensive, since it
requires reifying property descriptors for every check, but it should be a
relatively uncommon operation on cross-origin objects, and should not be
particularly expensive for any properties of a RemoteObjectProxy.
Differential Revision: https://phabricator.services.mozilla.com/D46734
--HG--
extra : moz-landing-system : lando
We support calling WebIDL prototype methods on cross-compartment objects as
long as they're same-type and same-origin. Any attempt to call them on
cross-origin wrappers with security policies leads to a security error.
Remote object proxies look and behave like cross-origin objects, but are not
technically wrappers. This means that for non-cross-origin-accessible
method/getter calls, we just treat them as same-origin objects which do not
implement the correct interface. Aside from being confusing, this makes it
easy for web content to distinguish between remote and in-process objects with
the same interface, which they generally should not be able to do.
Treating remote object proxies as if they were opaque wrappers solves these
problems.
Differential Revision: https://phabricator.services.mozilla.com/D46495
--HG--
extra : moz-landing-system : lando
Profile creation date (profile_date) is now embedded in Telemetry Activation Ping.
Differential Revision: https://phabricator.services.mozilla.com/D47097
--HG--
extra : moz-landing-system : lando
