We already have a mechanism for ending threads accepting new messages
when they are shut down, so this only allows tasks started from thread
shutdown tasks during xpcom shutdown to behave consistently.
We already didn't prevent dispatching to the background thread pool at
this time, so it should make little difference there as well, and may
just instead save us from deadlocks where code expects a dispatch to
succeed and it does not during actor shutdown.
This patch both relaxes the check to only be a NS_ASSERTION, and relaxes
it to allow dispatching to the current thread even after
xpcom-shutdown-threads as that thread is definitely still alive.
Differential Revision: https://phabricator.services.mozilla.com/D144592
This patch moves where we perform the final KillClearOnShutdown to occur
after we've shut down non-main threads, but before the main thread stops
accepting events. This should help ensure that unsuspecting events,
including those triggered from nsIThreadShutdownTask tasks, don't run
after KillClearOnShutdown has been run on background or main threads.
This KillClearOnShutdown was moved to occur before
nsThreadManager::Shutdown() in bug 1637890, as there were examples of
KillClearOnShutdown callbacks which needed to be able to dispatch
main-thread runnables. This change should not regress that use-case, as
we are still accepting new events on the main thread after the callback.
Non-main threads were already unreliable after this call as we already
block normal dispatches by setting gXPCOMThreadsShutdown, and new
threads cannot be started for the background thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D144591
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
Due to how this type of threadsafe refcounting is implemented, it needs to be
implemented using a MFBT-style refcounting base class, somewhat similar to
`SupportsWeakPtr`.
This patch makes NS_IMPL_{ADDREF,RELEASE}_INHERITED intelligently not add
refcount logging for types inheriting from SupportsThreadSafeWeakPtr, as the
default behaviour would break due to weak pointer upgrades not calling through
`AddRef` or `Release`.
In MFBT, the return value of `AddRef` and `Release` on
SupportsThreadSafeWeakPtr is changed to be compatible with nsISupports, so that
this type can be used to implement nsISupports refcounting.
Differential Revision: https://phabricator.services.mozilla.com/D142603
Make the APZ mochitests use coor coordinatesRelativeToScreen and its callers
properly. When was made async not everything was made to await properly.
Differential Revision: https://phabricator.services.mozilla.com/D144756
The general idea is that when extensions are installed at startup, they request permissions needed. Some examples of permissions might be access to downloads or bookmarks. This patch implements the ability to request permissions after install during runtime. A common optional permission is geolocation. The app won't request the user's location until needed.
GeckoView will provide a delegate to apps called onOptionalPrompt that provides the extension and the permissions the extension is requesting. They can then query the user to accept or reject the permission. The delegate works by listening to the browser API browser.permissions.request. Any browser API will be linked to a corresponding file and function such as ext-permissions.js::request() in this example. request() notifies observers of the topic webextension-optional-permission-prompt. ExtensionPromptObserver listens to that topic and dispatches an event GeckoView:WebExtension:OptionalPrompt. The geckoview web extension controller listens on that event and pass the extension and permissions to the skeleton delegate functions, that will get implemented by the app.
To verify this works, the test case WebExtensionTest.kt installs an extension through the package xpi. The package is created on build from moz.build to contain the extension's manifest.json and necessary scripts. Once the extension package is installed, we load the html script in the package that states when the page is clicked, trigger the browser API browser.permissions.request. The click is simulated with synthesizeTap. This request is then observed by listeners like mentioned in the previous paragraph. We verify in our skeleton delegate that the permissions provided match the ones requested.
Differential Revision: https://phabricator.services.mozilla.com/D143925
This patch does not impact behavior.
Before this patch, these variables' names are abbreviations of their original
type-name, "nsCSSOffsetState". We renamed that type to SizeComputationInput in
bug 1277129, and this patch just updates the variable-names to reflect that
renaming, so that now they're abbreviations of the new type-name, rather than
the old one.
This patch also takes this opportunity to move these variables declarations
closer to their usage, and in one case we convert a variable to be a temporary
anonymous value in the middle of another assignment.
Differential Revision: https://phabricator.services.mozilla.com/D145137
This patch doesn't impact behavior.
The namespace prefix is unnecessary, given the fact that this code is all
inside `namespace mozilla {...}`.
Differential Revision: https://phabricator.services.mozilla.com/D145136
This patch does not impact behavior; it's just a handful of renamings and
documentation-updates.
Before this patch, our float-handling code has a bunch of variables and
functions with "replaced" in the name. But in fact these aren't necessarily
replaced; they're just block-level frames that elicit a "false" return-value
from "BlockCanIntersectFloats". This category *includes* replaced boxes, and
it also includes frames that establish a formatting context, e.g.:
scrollframes, flex/grid containers, flow-root, table.
This patch seeks to clarify things by renaming these to refer to the fact that
they "avoid" floats, e.g. s/replacedBlock/floatAvoidingBlock/.
I've included a comment to reference this term in the BlockCanIntersectFloats()
documentation (note that the "can intersect" concept is the opposite of
"avoids"). I've also renamed a few "aFrame" variables to
"aFloatAvoidingBlock", for a few functions that are explicitly dealing with
this scenario and only expect to be passed frames that are in this category.
Differential Revision: https://phabricator.services.mozilla.com/D145131
We already have a mechanism for ending threads accepting new messages
when they are shut down, so this only allows tasks started from thread
shutdown tasks during xpcom shutdown to behave consistently.
We already didn't prevent dispatching to the background thread pool at
this time, so it should make little difference there as well, and may
just instead save us from deadlocks where code expects a dispatch to
succeed and it does not during actor shutdown.
This patch both relaxes the check to only be a NS_ASSERTION, and relaxes
it to allow dispatching to the current thread even after
xpcom-shutdown-threads as that thread is definitely still alive.
Differential Revision: https://phabricator.services.mozilla.com/D144592
This patch moves where we perform the final KillClearOnShutdown to occur
after we've shut down non-main threads, but before the main thread stops
accepting events. This should help ensure that unsuspecting events,
including those triggered from nsIThreadShutdownTask tasks, don't run
after KillClearOnShutdown has been run on background or main threads.
This KillClearOnShutdown was moved to occur before
nsThreadManager::Shutdown() in bug 1637890, as there were examples of
KillClearOnShutdown callbacks which needed to be able to dispatch
main-thread runnables. This change should not regress that use-case, as
we are still accepting new events on the main thread after the callback.
Non-main threads were already unreliable after this call as we already
block normal dispatches by setting gXPCOMThreadsShutdown, and new
threads cannot be started for the background thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D144591
This adds both the core Rust implementation and the
code to enable the needed language bindings. This
additionally enables GIFFT on the URL type, mirroring
them to a string scalar.
Differential Revision: https://phabricator.services.mozilla.com/D145215
This member is no longer used on Windows, and having it in the
base class doesn't provide a real abstraction anyway since
the child classes will break if anything about it is changed.
Differential Revision: https://phabricator.services.mozilla.com/D145132
Fenix's Picture-In-Picture uses full screen mode. So it isn't same as Firefox
Desktop. When exiting full screen, Fenix's window may not same as before
entering full screen.
When this occurs,
1. When device is portrait orientation, user changes to full screen by content
script.
2. Fenix enters to full screen then orientation is changed to landscape.
3. User changes that device is changed to landscape by hand.
4. Fenix enters PiP mode. Android (Home screen) change to portrait orientation.
Then PiP window keeps landscape orientation.
5. When exiting PiP, full screen will be exited.
6. Device is landscape (by Step 3.), so Fenix window is landscape. But Gecko
restores 1.'s viewport by `nsIDOMWindowUtils.exitFullScreen`. So viewport
becomes portrait orientation size even if window is landscape orientation.
For PiP mode, although nsIDOMWindowUtils.exitFullScreen is used, it doesn't
consider this situation. So I would like to add non-restore option for it.
Differential Revision: https://phabricator.services.mozilla.com/D143992
This patch causes us to trigger a rebuild for the python environment on browsertime upgrades and installations. This is needed for now because we are moving to python-based dependencies for visual-metrics processing and that requires a rebuild on the first upgrade/installation.
See bug 1766112 for the removal of this code.
Depends on D144464
Differential Revision: https://phabricator.services.mozilla.com/D144565
This patch forces us to re-install browsertime if FFMPEG is not found in the cache. This fixes an issue where deleting the `.mozbuild/browsertime` folder would go undetected and cause failures later when running browsertime.
Alongside these changes, the patch also enables detecting for FFMPEG on Linux, and Windows machines. It works in the same way as mac, but it also requires using `browsertime_ffmpeg` since the `os.environ` settings don't get transferred to the required environment.
Depends on D143603
Differential Revision: https://phabricator.services.mozilla.com/D144464
This patch modifies the mach browsertime file to use the new visualmetrics script and removes the usage, installation, and checks for ImageMagick.
Depends on D142838
Differential Revision: https://phabricator.services.mozilla.com/D143603
This patch runs the visual-metrics processing within the test task rather than the (deleted) `-vismet` tasks. It also updates the browsertime version to v15. It requires an update to node16 so new code was added to pull, and install the *-node-16 toolchain artifacts from CI.
This patch is possible because the browsertime update gives us the new `visualmetrics-portable.py` script which doesn't require ImageMagick anymore (they've been converted to Python dependencies). We did this conversion here: https://github.com/sitespeedio/browsertime/pull/1741
Furthermore, some changes are made to handle timeouts better, and increase the timeout for an interactive test.
Depends on D143502
Differential Revision: https://phabricator.services.mozilla.com/D142838
This patch adds the ability to raptor-browsertime for downloading, and installing a node binary from our Taskcluster CI. This makes it possible to seamlessly use raptor-browsertime with node-16, while using node-12 for the rest of the mozilla-central tooling.
Depends on D142837
Differential Revision: https://phabricator.services.mozilla.com/D143502
This patch removes all the code related to the second task (the `*-vismet` tasks) we were using for visual-metrics processing.
Differential Revision: https://phabricator.services.mozilla.com/D142837
