nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsWebShellWindow is the only class that extends nsXULWindow and only
nsWebShellWindows are ever instantiated.
Differential Revision: https://phabricator.services.mozilla.com/D51155
--HG--
extra : moz-landing-system : lando
This replaces mUpdatesCount in AsyncImagePipelineManager, which was really how
many times NotifyPipelinesUpdated was called with aRender == true. I think this
makes the release logic clearer as it is more explicit.
It also changes things for RenderCompositorANGLE, so that we check to see if
any other frames have completed even if we don't want to wait for them.
Differential Revision: https://phabricator.services.mozilla.com/D51064
--HG--
extra : moz-landing-system : lando
The code that uses these fields is part of a subsequent patch. This patch is just getting the tracing right.
Differential Revision: https://phabricator.services.mozilla.com/D48782
--HG--
extra : moz-landing-system : lando
Right now there BinAST is the only case, but subsequent patches will add GC pointers to XDR encoders and decoders.
Differential Revision: https://phabricator.services.mozilla.com/D48781
--HG--
extra : moz-landing-system : lando
This also removes the DrawEventRecorderPrivate::IsEmpty method as it is no
longer used. It doesn't undo the splitting out of the tracking of the
UnscaledFonts, which was added at the same time, because I think it is useful
to highlight the fact that they are never currently removed.
Differential Revision: https://phabricator.services.mozilla.com/D51593
--HG--
extra : moz-landing-system : lando
This doesn't fix every scenario, as chrome JS can still try to call one of these
methods, which will cause a crash. We would need to move SendLoadURI to PContent
so that chrome JS can navigate arbitrary contexts if we wanted to be certain no
crash occurred.
Unfortunately, chrome JS navigates in-process BrowsingContext objects very
frequently in tests (etc), so we can't make location navigations which don't have
an accessor fail.
I considered making the method just produce an error, rather than doing a
diagnostic assert, but I figured we should make that decision in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D50856
--HG--
extra : moz-landing-system : lando
The JSContext* is already fetched from within GetIncumbentGlobal, so the get is
guaranteed not to fail. This simplifies the callsite, making it easier to call.
Differential Revision: https://phabricator.services.mozilla.com/D50855
--HG--
extra : moz-landing-system : lando
These methods are only callable from the parent process, so it doesn't make
sense to have the method available driectly on BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D50854
--HG--
extra : moz-landing-system : lando
When creating grid and display badges in the markup view, ensure they listen only to their corresponding highlighter events.
Differential Revision: https://phabricator.services.mozilla.com/D51137
--HG--
extra : moz-landing-system : lando
@gl can you take a look at the DevTools test added here?
@nika @mconley I used this.browsingContext.docShell.isContent here to rule out chrome-privileged documents. Do you know if there is better way to check if the current document is chrome-privileged or not?
Differential Revision: https://phabricator.services.mozilla.com/D51320
--HG--
extra : moz-landing-system : lando
JS_BIT and JS_BITMASK are only used in contexts where uint32_t is used, so these
two functions are now typed to accept and return uint32_t.
JS_HOWMANY and the three JS_ROUND functions are only used with size_t inputs,
so these four functions are now typed to accept and return size_t.
Differential Revision: https://phabricator.services.mozilla.com/D51142
--HG--
extra : moz-landing-system : lando
Both macros compute the same result, so we can replace ROUNDUP with JS_ROUNDUP.
Differential Revision: https://phabricator.services.mozilla.com/D51141
--HG--
extra : moz-landing-system : lando
It started progressing as soon as we set up the rendering of the tracks in the
stream, which is too early according to the HTMLMediaElement spec.
Now it starts progressing when we're potentially playing. The difference being
that we now wait for mReadyState to go beyond HAVE_CURRENT_DATA before hooking
up the time progression mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D49354
--HG--
extra : moz-landing-system : lando
This makes all inputs to IsPotentiallyPlayin() Watchable when we're playing a
MediaStream.
Differential Revision: https://phabricator.services.mozilla.com/D49353
--HG--
extra : moz-landing-system : lando
Brendan Dahl
Nihanth Subramanya
Bob Owen
Michael Kaply
Erica Wright
Iain Ireland
Dorel Luca
Nathan Froyd
Nika Layzell
Byron Campen [:bwc]
Razvan Caliman
Julian Descottes
Ionut Goldan
Neil Deakin
André Bargull
Nicolas Silva
Christoph Walcher
Nicolas Chevobbe
Kershaw Chang
Mihai Alexandru Michis
Kurt Miller
Jeff Muizelaar
Andreas Pehrson
ffxbld
Mark Banner
Andrea Marchesini