This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
The only thing it's used for is calling will paint on a document tree. To iterate every viewmanager looking for those in one document tree is a bit silly, we can just walk the view tree. Since there are only 3 types of views (root views, popup views for menupopupframes, and subdocument frame views (and their inner view)) we don't have to walk many pointers: menupopupframes are controlled by chrome code and are limited, and the other two types of views correspond to the number of view managers in the tree (one view manager per document).
Differential Revision: https://phabricator.services.mozilla.com/D180677
Turns out we already had code for this in NumericTools.h, so reuse it.
I thought I was going to need this code somewhere else though I didn't
end up needing it.
While at it clean up unnecessary template params I noticed.
Differential Revision: https://phabricator.services.mozilla.com/D168460
It's a more natural place for it to live, since it concerns only the
root view.
Clean up a bit while at it, and factor out the window size constraints,
which we're going to use momentarily.
Differential Revision: https://phabricator.services.mozilla.com/D168461
Let the caller addref it if needed.
I wrote this because I wanted to make some code dealing with it
thread-safe, but I ended up writing a less sketchy solution. However I
still think this is worth it.
It seems this only returns an already_AddRefed because before it used to
be an XPCOM-ish thing where the widget was returned as an out-param.
For now it doesn't change behavior but there are some callers that would
benefit from having less addref/release calls if they only need to read
simple stuff from the widget.
Differential Revision: https://phabricator.services.mozilla.com/D168141
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
The current implementation of TimelineConsumers contains some unnecessary
complexity due to how it is initialized as a singleton, and the need for it to
be initialized and used in a threadsafe way. This patch attempts to simplify it
by making all members static, and removing the need to explicitly observe
shutdown for cleanup.
In addition, this approach avoids the risk of the type being accessed from
off-main-thread during initialization or shutdown.
Depends on D150442
Differential Revision: https://phabricator.services.mozilla.com/D150443
This patch adds plumbing to keep track of why we request frames to be rendered.
This information is then displayed in gecko profile markers on the renderer thread as well as in profiler HUD counters (See "Render reasons" in profiler.rs).
Differential Revision: https://phabricator.services.mozilla.com/D127274
This lets us remove the last explicit 'delete' invocation from the /view
subdirectory. Hooray!
As part of this change, I'm also updating the getter for this member-var to
return a reference instead of a pointer, since it's infallible.
Differential Revision: https://phabricator.services.mozilla.com/D127187
This removes an explicit 'delete', by letting the StaticAutoPtr type handle the
deletion for us automatically and atomically when we clear its value.
Benefits/justification:
* This reduces the potential for double-free bugs.
* This matches existing patterns elsewhere in our code
(search for e.g. "StaticAutoPtr<nsTArray")
* This reduces (by 1) the number of explicit `delete` calls that we need to
consider, when auditing the codebase for potential memory safety issues.
Differential Revision: https://phabricator.services.mozilla.com/D127185
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch is just a refactoring which shouldn't change behavior.
Before this patch, mRootViewManager is a bit of an odd hybrid in terms of its
ownership semantics. If it's pointing to `this`, then it's not an owning
reference (i.e. we don't AddRef or Release it), vs. if it's pointing to some
other instance, then it *is* an owning reference (i.e. we *do* AddRef and
Release it).
After this patch, we change things such that it's unconditionally an owning
reference, with a null value having special meaning.
In particular:
(a) Now, we'll store it in a RefPtr and let that manage the reference counting.
(b) Now, we'll never explicitly assign it to 'this'; instead, we set it to null
and we interpret a null value as an indication that 'this' is the root.
Fortunately, this variable doesn't have many direct usages, so this slight
change in meaning/invariatnts doesn't require very much code to be updated.
This variable is mostly used via the infallible RootViewManager() getter. This
patch updates that getter in accordance with the new contract, and the callers
don't need to worry about this change.
Differential Revision: https://phabricator.services.mozilla.com/D127178
This lets us remove the last explicit 'delete' invocation from the /view
subdirectory. Hooray!
As part of this change, I updated the getter for this member-var to return a
"const UniquePtr&" instead of a raw pointer, per this recommendation in
UniquePtr.h:
https://searchfox.org/mozilla-central/rev/7539ad54ddc720a0553efd07ca681b9a409f9887/mfbt/UniquePtr.h#171-173
(Fortunately the getter only has two callers, so they were easy to fix.)
I also changed the name of the getter to drop "Get", per our convention that
getters can hint at infallibility by the absence of "Get".
Depends on D127185
Differential Revision: https://phabricator.services.mozilla.com/D127187
This removes an explicit 'delete', by letting the StaticAutoPtr type handle the
deletion for us automatically and atomically when we clear its value.
Benefits/justification:
* This reduces the potential for double-free bugs.
* This matches existing patterns elsewhere in our code
(search for e.g. "StaticAutoPtr<nsTArray")
* This reduces (by 1) the number of explicit `delete` calls that we need to
consider, when auditing the codebase for potential memory safety issues.
Depends on D127180
Differential Revision: https://phabricator.services.mozilla.com/D127185
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch is just a refactoring which shouldn't change behavior.
Before this patch, mRootViewManager is a bit of an odd hybrid in terms of its
ownership semantics. If it's pointing to `this`, then it's not an owning
reference (i.e. we don't AddRef or Release it), vs. if it's pointing to some
other instance, then it *is* an owning reference (i.e. we *do* AddRef and
Release it).
After this patch, we change things such that it's unconditionally an owning
reference, with a null value having special meaning.
In particular:
(a) Now, we'll store it in a RefPtr and let that manage the reference counting.
(b) Now, we'll never explicitly assign it to 'this'; instead, we set it to null
and we interpret a null value as an indication that 'this' is the root.
Fortunately, this variable doesn't have many direct usages, so this slight
change in meaning/invariatnts doesn't require very much code to be updated.
This variable is mostly used via the infallible RootViewManager() getter. This
patch updates that getter in accordance with the new contract, and the callers
don't need to worry about this change.
Differential Revision: https://phabricator.services.mozilla.com/D127178
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Adam Brouwers-Harries
Narcis Beleuzu
Emilio Cobos Álvarez
Timothy Nikkel
Makoto Kato
Iulian Moraru
Butkovits Atila
Botond Ballo
Sandor Molnar
Cristian Tuns
Nika Layzell
stransky
Jeff Muizelaar
Nicolas Silva
Daniel Holbert
Matt Woodrow
Andi-Bogdan Postelnicu
Gijs Kruitbosch
Mike Hommey
Csoregi Natalia