This comes back to ~since forever, since absolutely positioned elements
used to have views. But now is basically only plumbed from
nsMenuPopupFrame to nsIWidget.
The main issue is that that concept is basically fiction nowadays:
* Wayland can't reorder popups.
* macOS doesn't implement it because SetZIndex calls PlaceBehind which
only has a windows impl.
* Unclear whether it works properly on Windows as well.
Also, the front-end never sets it anyways.
So remove this fiction to simplify relevant code. We might want to
provide a z-ordering of popups somehow else, but it should probably live
in nsXULPopupManager etc rather than nsView.
Differential Revision: https://phabricator.services.mozilla.com/D213598
A version of the patch in bug 1895870 caused some WPT tests to time out
because document.fonts.ready never resolves.
This is because I made PresShell::HasPendingReflow look at
mNeedLayoutFlush, and nsIFrame::SchedulePaint() calls
PresShell::ScheduleViewManagerFlush() which sets that bit.
So we end up with mNeedLayoutFlush, but without a flush scheduled, and
the ready promise doesn't resolve until something else schedules a
flush. I fixed the original patch to preserve behavior, but requesting a
repaint shouldn't require a layout flush.
This call was added in bug 598482 part 16:
https://hg.mozilla.org/mozilla-central/rev/71d77495b606fc145bdceabcda29181978bd9405
We only need the layout flush if there are view geometry updates, so
shift the call up to the view manager.
Differential Revision: https://phabricator.services.mozilla.com/D209938
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
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
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
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
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
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
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
mHasScheduleFlush is meant to track mViewManagerFlushIsPending except mViewManagerFlushIsPending gets set to false just before we call ProcessPendingUpdates, whereas mHasScheduleFlush is set to false just after we call ProcessPendingUpdates.
There are a couple places where mViewManagerFlushIsPending gets set to false that don't clear mHasScheduleFlush though. This leaves mHasScheduleFlush true until we get another paint that changed something. This causes this code
https://searchfox.org/mozilla-central/rev/3a0a8e2762821c6afc1d235b3eb3dde63ad3b01a/layout/painting/nsDisplayList.cpp#3058
in nsDisplayList::PaintRoot to always notify of invalidation (with webrender). This in turn causes a loop in the reftest harness: notify invalidation -> mozafterpaint -> update canvas -> paint -> notify invalidation.
This code changed a bunch until settling on the current design in bug 1404091.
Differential Revision: https://phabricator.services.mozilla.com/D61738
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
This patch makes `nsViewManager::GetPresShell()` and
`nsIWidgetListener::GetPresShell()` (overridden by `nsView` and
`nsWebShellWindow::WidgetListenerDelegate`) return `mozilla::PresShell*`.
Additionally, makes `nsWebShellWindow::GetPresShell()` also return
`mozilla::PresShell()`.
Differential Revision: https://phabricator.services.mozilla.com/D26454
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Emilio Cobos Álvarez