accessible/base/TreeWalker.cpp:151:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
accessible/xpcom/xpcAccessibleMacInterface.mm:177:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]

Differential Revision: https://phabricator.services.mozilla.com/D126173

Other items types that support flattening return false from CanHandleOpacity if their CreateWebRenderCommands implementation will fail. That's really hard to determine in advance for text, so it's simpler to just handle the opacity in the fallback path too.

Differential Revision: https://phabricator.services.mozilla.com/D125634

Bug 1727674 - Replace nsLayoutUtils::GetCrossDocParentFrame with nsLayoutUtils::GetCrossDocParentFrameInProcess in nsIFrame::UpdateVisibilitySynchronously. r=tnikkel

Differential Revision: https://phabricator.services.mozilla.com/D125126

One caveat is that this change doesn't mean we handle frame visibility in
iframes in a same manner regardless whether the iframe is out-of-process or not.
In fact, we handle OOP iframe cases in a slightly different way since in OOP
iframes if the iframe is invisible because it's scrolled out or some such, then
we can't tell how far the iframe is from the visible scroll port. For example;

```
<div style="height: 100px; overflow: scroll;">
  <div id="spacer" style="width: 100%; height: 200px;"></div>
  <iframe style="height: 100px;"></iframe>
</div>
```

In this case, we consider all frames inside the iframe are invisible because
the iframe position is out of our frame visibility tracking margins. But if
the #spacer element's height is 100px, we consider all frames inside the iframe
viewport are visible if the iframe is in-process iframe, whereas we consider
all frames are invisible if the iframe is out-of-process iframe.

So in short, the frame visibilityn inside OOP iframes is depending on whether
the iframe gets painted in the parent document, i.e. depending on display port
and other factors controlling the paint stuff, the visibility inside in-process
iframes is depending on same factors for normal scrollable frames.

Differential Revision: https://phabricator.services.mozilla.com/D125125

Bug 1718444 - Add testing that update-available prompts are not shown incorrectly r=nalexander,application-update-reviewers

Added testing that multiple update downloads per session (Bug 353804) works properly with or without automatic update downloading.

Depends on D126162

Differential Revision: https://phabricator.services.mozilla.com/D126163

I want to be able to check if the update-available notification is fired during testing. The entry point to firing that notification is UpdateService.onCheckComplete, but it currently kicks off its work and does not wait for it to finish. This means that I can wait for the update-available notification to be fired, but I cannot easily wait for it NOT to be fired, which is what I want to be able to test here.

It looks though like it should be easy enough to just convert this interface to an asynchronous one. This will make it much easier to call onCheckComplete and know by the end of it if the update-available notification gets fired or not.

Differential Revision: https://phabricator.services.mozilla.com/D126162

Bug 1718444 - Don't show the update-available prompt if we aren't going to download the update r=nalexander,application-update-reviewers

This patch fixes an issue where it is possible to show the update-available prompt to the user for an update that will not ultimately be downloaded. This can result in many unnecessary update-available prompts. The issue is that `AUS.downloadUpdate` makes some checks to ensure that it doesn't download updates if, for example, that exact update has already been downloaded. But the update-available prompt is shown before `AUS.downloadUpdate` is called.


Depends on D126163

Differential Revision: https://phabricator.services.mozilla.com/D126164

For non-WR painting from nsDisplayList::Paint, the display item clip will already be applied to the context, so will still be included in the result via the clip extents.
WebRender fallback painting intentionally doesn't use the clip (since the clip can include the displayport size), to avoid needing to invalidate for display port changes..

Differential Revision: https://phabricator.services.mozilla.com/D125613

Bug 1725433 - Replace placeholder image with a screenshot of the current viewport in new screenshots UI. r=emalysz

Differential Revision: https://phabricator.services.mozilla.com/D126292

The pre-existing code for printing a function type to string used a check
behind 'fuzzingSafe' and I cannot find a reason for this in any
commit history. Searchfox thinks it came from the original commit
for the imports/exports feature from luke, but it's not present
in the commits he landed, nor in the bug. I don't think it's
necessary, so I think we should remove it while we're fixing
this bug.

Differential Revision: https://phabricator.services.mozilla.com/D125979

Backed out changeset da95455590d7 (bug 1475641) for marionette crashes on test_profile_management.py . CLOSED TREE

Backed out changeset ceaaed353b66 (bug 1725430) for assertion failure on ErrorResult.h . CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D125938

As of now, wine is used with:
- fxc, which is detected in toolkit/moz.configure
- midl, which is detected in toolkit/moz.configure
- ml64 or armasm64, for some assembly sources that aren't used in
  projects that don't include toolkit/moz.configure.

We can thus move it there.

As of bug 1731195, there is no remaining use of wine for artifact
builds, so we also make it limited to builds with a compile environment.

Differential Revision: https://phabricator.services.mozilla.com/D126166

Add columns for scrolling time and distance to the interactions view and also export these fields for analysis.

Differential Revision: https://phabricator.services.mozilla.com/D126261

Bug 1696251: Allow mach commands as stand-alone functions and adapt existing commands. r=mhentges,webdriver-reviewers,perftest-reviewers,sparky,whimboo

This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.

Differential Revision: https://phabricator.services.mozilla.com/D121512

Differential Revision: https://phabricator.services.mozilla.com/D126275

Bug 1725430: disable screenshot shortcut for extension when screenshots.browser.component.enabled is true. r=emalysz,fluent-reviewers,flod

Differential Revision: https://phabricator.services.mozilla.com/D125850

Backed out changeset 909bf2399362 (bug 1726550) for causing bc failures on browser_contextmenu.js. CLOSED TREE

Use the dav1d value for color_range even when color_description_present is false

Differential Revision: https://phabricator.services.mozilla.com/D126160

Differential Revision: https://phabricator.services.mozilla.com/D125855

Differential Revision: https://phabricator.services.mozilla.com/D124748

Differential Revision: https://phabricator.services.mozilla.com/D121276

Differential Revision: https://phabricator.services.mozilla.com/D121275

Bug 1688791 - Part 8: Remove virtual from XDRState and cast to XDRStencilDecoder when getting options. r=tcampbell

Differential Revision: https://phabricator.services.mozilla.com/D121274

Differential Revision: https://phabricator.services.mozilla.com/D121273

Differential Revision: https://phabricator.services.mozilla.com/D121272

Differential Revision: https://phabricator.services.mozilla.com/D121271

Differential Revision: https://phabricator.services.mozilla.com/D121270

Differential Revision: https://phabricator.services.mozilla.com/D121269

Differential Revision: https://phabricator.services.mozilla.com/D121268

Differential Revision: https://phabricator.services.mozilla.com/D121267

The Intel DDX driver is known to cause troubles with HW-WR and
has been deprecated by most distributions, in favor of the glamor
based "modesetting" driver.

Lets blocklist it. This will mostly affect older/legacy setups.

Note: the xrandr boilerplate code in glxtest will be useful for
better multi-screen detection in a follow up patch. The current
legacy X11 screen detection does not work in composited environments,
always reporting one single big screen with the combined size.
Xrandr allows for correct detection in such setups.

Differential Revision: https://phabricator.services.mozilla.com/D126221

Bug 1728638 - Parameters to set MSIX `Package/Identity/{Name,Publisher}` and `Package/Properties/PublisherDisplayName`. r=bhearsum

This is just rearranging some deck chairs as we hammer out details in
our MSIX package publication pipeline.

Differential Revision: https://phabricator.services.mozilla.com/D124264

Bug 1728472 - Part 2: Restrict advertised languages in MSIX to allow-list from Windows. r=bhearsum,flod

Windows MSIX packages support a finite set of locales: see
https://docs.microsoft.com/en-us/windows/uwp/publish/supported-languages.
This patch encodes that list in
browser/installer/windows/msix/msix-all-locales.  Two ad-hoc
modifications were necessary: removing 'sr*' (Serbian) and 'uz*'
(Uzbek) in order for the resulting MSIX packages to install.

We distribute all of the langpacks supported by the release channel in
our MSIX, which is encoded in browser/locales/all-locales.  But we
only advertise support in the App manifest for the intersection of
that set and the set of locales supported by Windows.

We do so to avoid the following issue.  Suppose a user manually
installs a langpack that is not supported by Windows, and then updates
the installed MSIX package.  MSIX package upgrades are essentially
paveover installs, so there is no opportunity for Firefox to update
the langpack before the update.  But, since all langpacks are bundled
with the MSIX, that langpack will be up-to-date, preventing one class
of YSOD.

Differential Revision: https://phabricator.services.mozilla.com/D126175

Differential Revision: https://phabricator.services.mozilla.com/D124263

Bug 1726214 - Post: Create MSIX packages with langpacks in language-specific subdirectory. r=bhearsum

Differential Revision: https://phabricator.services.mozilla.com/D126174

Differential Revision: https://phabricator.services.mozilla.com/D115421

Tier-2 tasks are finished on a helper thread and don't have a
JSContext* to report errors/warnings to. It may be useful for
end-users or engine developers to be notified when a tier-2
task fails and why. This commit implements logging of errors
and warnings by printing to stderr.

An alternative approach would be to get a runnable on the
originating JS thread that reports the errors/warnings using
that *JSContext. I'm not sure the best way to do this, so I
went with the simpler approach for now.

Differential Revision: https://phabricator.services.mozilla.com/D125585