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
When nsView::CalcWidgetBounds() size might be applied to widget with modification. And next widget->GetClientBounds() could be different than nsView::CalcWidgetBounds() again with several reasons. But it seems OK to apply widget->ConstrainSize() in nsView::DoResetWidgetBounds(). It could remove repaint because of widget->ConstrainSize() call in the Resize().
Differential Revision: https://phabricator.services.mozilla.com/D114814
When nsView::CalcWidgetBounds() size might be applied to widget with modification. And next widget->GetClientBounds() could be different than nsView::CalcWidgetBounds() again with several reasons. But it seems OK to apply widget->ConstrainSize() in nsView::DoResetWidgetBounds(). It could remove repaint because of widget->ConstrainSize() call in the Resize().
Differential Revision: https://phabricator.services.mozilla.com/D114814
