Until we have clang builds, we want nightlies to be built with msvc, so
configure the nightly build as msvc.
Differential Revision: https://phabricator.services.mozilla.com/D14657
--HG--
extra : moz-landing-system : lando
XZ supports rewritting addresses in executable code, which is architechture
specific. The updater is compiled with support for the target architecture
only, so we can't always compress updates passing `--x86` to XZ. This threads
the architecture through to the repackage steps, so we can pass the appropraite
flags to the update packaging scripts.
Differential Revision: https://phabricator.services.mozilla.com/D14601
--HG--
extra : moz-landing-system : lando
Depends on D14709
So far, because we supported only single device, we could correspond to
disconnection by following code. From now, because we will support multi
devices, fix the code that changes the status.
Differential Revision: https://phabricator.services.mozilla.com/D14831
--HG--
extra : moz-landing-system : lando
This initializes a one of the stats that lost its default initialization when it was changed from an Atomic to a plain old int.
Differential Revision: https://phabricator.services.mozilla.com/D14978
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
This moves the CHANGELOG.md file to a /doc-files folder that gets picked up by
javadoc.
Our javadoc files are hosted on a github.io page which will render the markdown
file with the geckoview profile.
Depends on D13883
Differential Revision: https://phabricator.services.mozilla.com/D14786
--HG--
rename : mobile/android/geckoview/CHANGELOG.md => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/doc-files/CHANGELOG.md
extra : moz-landing-system : lando
Although this task technically doesn't build a toolchain, the set of
steps it needs to do is very similar to what a toolchain build does, so
we're shoehorning this task into the toolchain kind. The task basically
runs `cargo vendor` on the gfx/wr/Cargo.lock file (if/when it changes)
and exports a tarball of the resulting vendored crates. This allows
downstream tasks that build stuff in gfx/wr to not have to re-fetch
these crates from crates.io on every test run.
Differential Revision: https://phabricator.services.mozilla.com/D14406
--HG--
extra : moz-landing-system : lando
Depends on D14310. This patch enables displaying devices on which the debuggable
runtime is not started yet. To test it, simply use an android phone with USB debugging enabled
but don't start Firefox yet. You should see the Unknown Runtime item in the sidebar.
Not that once you start Firefox on the device, you need to click refresh runtimes here to get
the sidebar to refresh (more on that in the last patch of the series).
Two things I am not completely happy with:
- calling this a runtime, when really it's just a device that has no runtime.
but I don't want to start renaming all our state for that. Hope we can treat it as
placeholder runtime, and forget about it.
- localization for the runtime item name can be done in many ways. Not using getString
at all makes things really complicated, but I'm open to suggestions if you have any
Differential Revision: https://phabricator.services.mozilla.com/D14313
--HG--
extra : moz-landing-system : lando
Depends on D14309. Relying on head_mocks will make it easier to
update the mocks when we start calling isUnknown() on our USB runtimes.
Differential Revision: https://phabricator.services.mozilla.com/D14310
--HG--
extra : moz-landing-system : lando
Depends on D14307. Introduce a placeholder UnknownAdbRuntime extending AdbRuntime.
AdbRuntime implements isUnknown(). This method is used to filter out the unknown runtimes in
webide and about:debugging. (filter will be removed in about:debugging in a patch in the same
queue)
Differential Revision: https://phabricator.services.mozilla.com/D14309
--HG--
extra : moz-landing-system : lando
The model information is duplicated between adb runtime and adb device.
This allows to keep the information in a single place.
Differential Revision: https://phabricator.services.mozilla.com/D14307
--HG--
extra : moz-landing-system : lando
This appears to "just work."
While I would like to convert this image to Debian and make it
deterministic, that is more effect than I'm willing to invest at the
moment.
The impetus for this change is unblocking partial clones. Mercurial's
SQLite storage backend apparently hits a SQLite bug in version 3.11
of SQLite (what Ubuntu 16.04 runs) where SQLite complains about
database corruption when there are readers from multiple processes.
Ubuntu 18.04 is running SQLite 3.22 and doesn't exhibit the buggy
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D14228
--HG--
extra : moz-landing-system : lando
Depends on D14589. I did a first cleanup when migrating the first
service worker test, but I think we can go a bit further, and this is not
strictly related to the new test I am about to add.
Differential Revision: https://phabricator.services.mozilla.com/D14590
--HG--
extra : moz-landing-system : lando
Looks like we missed this feature when doing the initial service worker support
so implementing here. UI-wise, I reused the same wording/positioning etc as in the current
about:debugging.
Note that this is another spot that uses client.request, so we will need to clean this up
when we finally add a front to represent service worker registrations.
Differential Revision: https://phabricator.services.mozilla.com/D14589
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
The test failed if onHighlighted was received late, since it has an array of IDs. This change should address any case where we need to get the tab from id.
Differential Revision: https://phabricator.services.mozilla.com/D14860
--HG--
extra : moz-landing-system : lando
