StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This is used by some gfx code and is required to convert gfxPrefs into StaticPrefs.
The setter only modifies the value of the StaticPref in the current process and doesn't propagate to others.
Differential Revision: https://phabricator.services.mozilla.com/D31254
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
We should resolve video playing promise when we finish playing the last frame. Otherwise, it would cause playback to be ended earlier than its original duration.
Differential Revision: https://phabricator.services.mozilla.com/D32051
--HG--
extra : moz-landing-system : lando
Soon XUL documents will be loaded as XHTML and createElement will create HTML
elements instead of XUL element by default. This restriction can be removed
once we migrate everything.
Differential Revision: https://phabricator.services.mozilla.com/D31294
--HG--
extra : moz-landing-system : lando
When pinch zooming webrender would re-rasterize glyphs for each tiny
difference in zoom level. This takes time in itself, but also causes
the texture cache to grow incredibly large, to the point where
resizing it to make room for more glyphs takes far too much time.
This patch avoids this by rounding the size at which glyphs are
rasterized whilst pinch zooming. To do this we add a FrameMsg which
APZ uses to tell webrender whether a spatial node is being pinch
zoomed. Then during frame building if a spatial node is being pinch
zoomed we override the raster space of its corresponding picture.
The chosen raster space is the current zoom level rounded up to the
nearest power of two, but not exceeding 8x. This seems to be a good
balance between quality and performance, though at high zoom levels
the cache still does grow very large due to the size of the glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D30213
--HG--
extra : moz-landing-system : lando
Fixes the case reported where disabling the maintenance service caused the UI to display Applying due to the update staging failure.
Added new error codes for the two cases where pending was written to the update.status file when staging failed.
Added code to UpdateService.jsm to set the update.status to pending when either of the two new error codes are in the update.status file.
Added two new tests that verify the UI and simulate the failure condition in updater.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D32177
--HG--
extra : moz-landing-system : lando
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put certain preferences
into those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
This patch gives the RDM UI the ability to update the screen orientation based on the orientation of the simulated device screen. It fixes the following issues:
- Initializing the orientation state of the selected device when RDM is opened.
- Updating orientation state when the rotate button in the RDM toolbar is pressed.
- Updating the orientation state when a new device is selected.
There are three actions creators that are responsible for notifying the ResponsiveUI manager, `changeDevice`, `restoreDeviceState`, and `rotateViewport`. In particular:
- `restoreDeviceState` is dispatched when the Responsive UI has finished initializing. If a previous RDM session had a device selected, then this action creator will also dispatch the `changeDevice` action to update the RDM UI to reflect the currently selected device.
- `changeDevice` is dispatched when a device is selected.
- `rotateViewport` is dispatched when the rotate button is clicked in the RDM toolbar.
When either of these actions is dispatched, we post a "viewport-orientation-change" message to the window that notifies the manager to update the screen orientation accordingly.
Finally, when RDM is closed, we need to ensure the original physical screen orientation is restored. We do this by calling the `setRDMPaneOrientation` on the docShell's document in the content frame script.
Differential Revision: https://phabricator.services.mozilla.com/D30440
--HG--
extra : moz-landing-system : lando
This patch contains two isolated changes related to upcoming picture
caching improvements. Specifically:
* Determine the blit reason for stacking contexts with clips
earlier, during scene building. This simplifies the code and
allows better detection of redundant stacking contexts.
* Centralize the code for pushing batch instances into a small
number of places. This will simplify the switch to adding
a single primitive to multiple batch lists, in the case of
dirty regions with different batchers.
Differential Revision: https://phabricator.services.mozilla.com/D31898
--HG--
extra : moz-landing-system : lando
When restoreState is called early in a GeckoSession's life, the scroll position restore code can catch the pageshow event for the initial about:blank load rather than for the page being restored, resulting in a failure to restore scroll position.
Differential Revision: https://phabricator.services.mozilla.com/D32163
--HG--
extra : moz-landing-system : lando
Also take the oppurtunity to include "mac" in the filename to clarify
where it's used.
Differential Revision: https://phabricator.services.mozilla.com/D32058
--HG--
rename : browser/base/content/hiddenWindow.xul => browser/base/content/hiddenWindowMac.xhtml
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
