On Android the platform name capability has to report "android" and not "linux".
Also for every application which is embedding GeckoView "firefox" will be used
as browser name. That way it behaves the same like Chrome, which does it for
every WebView embedding application.
Depends on D44896
Differential Revision: https://phabricator.services.mozilla.com/D45363
--HG--
extra : moz-landing-system : lando
This allows to port-forward using adb. Connecting to such ports
always establishes a TCP connection to the ADB daemon, but not all
such connections are to bound ports. Waiting for the Marionette
handshake ensures the connection is real, and not just partially
forwarded.
Depends on D44895
Differential Revision: https://phabricator.services.mozilla.com/D44896
--HG--
extra : moz-landing-system : lando
This implementation speaks the ADB wire protocol over TCP/IP. This is
in constrast to the Python implementation, which generally invokes adb
on the command line. In thousands of runs across multiple devices,
this implementation has proved surprisingly robust.
Differential Revision: https://phabricator.services.mozilla.com/D44895
--HG--
extra : moz-landing-system : lando
This approach does have some stacking issues. The way to fix this would
be to instrument the brush_image shader rather than adding debug rects.
Something like: #ifdef WR_FEATURE_SFW frag.color = vec4(0,1,1,1); #endif
That's slightly more involved though, so I'm going to leave it for now.
Differential Revision: https://phabricator.services.mozilla.com/D47155
--HG--
extra : moz-landing-system : lando
NFC. The select operator will be given an array of result types, so this commit
requisitions AstTernaryOperator to be a dedicated select ast node. There's no
other uses of AstTernaryOperator, so this is just a rename.
Differential Revision: https://phabricator.services.mozilla.com/D45865
--HG--
extra : moz-landing-system : lando
This commit renames TVar to represent the new Bottom type introduced in the
reference types spec.
Issue: https://github.com/WebAssembly/reference-types/issues/42
The only observable spec change so far is in validation of br_table which
requires that the operand type is a subtype of all label types. With a bottom
type, this may allow more code to validate than before.
Differential Revision: https://phabricator.services.mozilla.com/D46641
--HG--
extra : moz-landing-system : lando
Issue: https://github.com/WebAssembly/reference-types/issues/42
The existing select instruction contains no typing information. As more
complicated types are added, we will need to infer the result type as the
least upper bound of the operands. This may be a complicated operation,
so we will restrict the existing untyped instruction to operate only on
the MVP value types, and add a new select instruction with type information.
Differential Revision: https://phabricator.services.mozilla.com/D45863
--HG--
extra : moz-landing-system : lando
This changes:
1. Take `NumberOperandId` at the part which can use the result of `CacheIRWriter.guardIsNumber()`.
2. Use `NumberOperandId` as a function signature which would only take a number operand.
* There are some exceptions, i.e.`CacheIRWriter.writer.truncateDoubleToUInt32()`,
because `NumberOperandId` is not always `double`.
Differential Revision: https://phabricator.services.mozilla.com/D46707
--HG--
extra : moz-landing-system : lando
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