- Sep 22, 2021
-
-
Matt Woodrow authored
Differential Revision: https://phabricator.services.mozilla.com/D125797
-
Matt Woodrow authored
PaintFrame only uses the input region if !WidgetLayers, which Paint always passes. Differential Revision: https://phabricator.services.mozilla.com/D125795
-
Chris Peterson authored
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
-
Matt Woodrow authored
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
-
Hiroyuki Ikezoe authored
Bug 1727674 - Replace nsLayoutUtils::GetCrossDocParentFrame with nsLayoutUtils::GetCrossDocParentFrameInProcess in nsIFrame::UpdateVisibilitySynchronously. r=tnikkel Differential Revision: https://phabricator.services.mozilla.com/D125126
-
Hiroyuki Ikezoe authored
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
-
- Sep 21, 2021
-
-
Kirk Steuber authored
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
-
Kirk Steuber authored
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
-
Kirk Steuber authored
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
-
Matt Woodrow authored
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
-
Niklas Baumgardner authored
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
-
Ryan Hunt authored
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
-
Narcis Beleuzu authored
Backed out changeset da95455590d7 (bug 1475641) for marionette crashes on test_profile_management.py . CLOSED TREE
-
Narcis Beleuzu authored
Backed out changeset ceaaed353b66 (bug 1725430) for assertion failure on ErrorResult.h . CLOSED TREE
-
Mike Hommey authored
Differential Revision: https://phabricator.services.mozilla.com/D125938
-
Mike Hommey authored
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
-
Andrew Creskey authored
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
-
Alex Lopez authored
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
-
Alex Lopez authored
Differential Revision: https://phabricator.services.mozilla.com/D126275
-
Emma Malysz authored
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
-
Marian-Vasile Laza authored
Backed out changeset 909bf2399362 (bug 1726550) for causing bc failures on browser_contextmenu.js. CLOSED TREE
-
Marian-Vasile Laza authored
-
Jon Bauman authored
Use the dav1d value for color_range even when color_description_present is false Differential Revision: https://phabricator.services.mozilla.com/D126160
-
Kershaw Chang authored
Differential Revision: https://phabricator.services.mozilla.com/D125855
-
Kershaw Chang authored
Differential Revision: https://phabricator.services.mozilla.com/D124748
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121276
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121275
-
Tooru Fujisawa authored
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
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121273
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121272
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121271
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121270
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121269
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121268
-
Tooru Fujisawa authored
Differential Revision: https://phabricator.services.mozilla.com/D121267
-
Robert Mader authored
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
-
Nick Alexander authored
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
-
Nick Alexander authored
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
-
Nick Alexander authored
Differential Revision: https://phabricator.services.mozilla.com/D124263
-
Nick Alexander authored
Bug 1726214 - Post: Create MSIX packages with langpacks in language-specific subdirectory. r=bhearsum Differential Revision: https://phabricator.services.mozilla.com/D126174
-