These functions all have a single call site, and the call site clearly always
has rect in DesktopPixel units. So it makes sense to encode this in the API,
and propagate the strongly typed units.
Differential Revision: https://phabricator.services.mozilla.com/D67696
--HG--
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
And fix a bunch of fallout as we now don't include nsDocShell.h everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D62169
--HG--
extra : moz-landing-system : lando
We are going to introduce a new function in Document in this commit series,
which enumerates all child documents regardless of whether it's in the same
process, in content processes or in out-of-process iframes. The function takes
std::functions, but I don't have any good ideas to convert lambda functions with
capturing variables to function pointer.
Differential Revision: https://phabricator.services.mozilla.com/D57434
--HG--
extra : moz-landing-system : lando
We are going to introduce a new function in Document in this commit series,
which enumerates all child documents regardless of whether it's in the same
process, in content processes or in out-of-process iframes. The function takes
std::functions, but I don't have any good ideas to convert lambda functions with
capturing variables to function pointer.
Differential Revision: https://phabricator.services.mozilla.com/D57434
--HG--
extra : moz-landing-system : lando
The dynamic toolbar transition doesn't affect on background tabs since to
switch tabs the dynamic toolbar should be restored to its original state (i.e.,
completely visible state).
Differential Revision: https://phabricator.services.mozilla.com/D52336
--HG--
extra : moz-landing-system : lando
And deliver the value to the top content pres context, but it's not used in
this commit. The value will be used in the next commit.
One caveat is that areas covered by the dynamic toolbar will be outside
of the content area, which means implementers of GeckoView needs to call
setVerticalClipping with _negative_ values.
Depends on D50416
Differential Revision: https://phabricator.services.mozilla.com/D50417
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
This is a weird pref.
First, it is VarCached into two different global variables, one in
nsSubDocumentFrame.cpp, and the other in nsView.cpp.
Second, the pref is not defined by default. When the VarCache variables are
initialized they are therefore set to the default value provided to the
`AddBoolVarCache()` call, which in both cases is `true`. This semantics isn't
possible with `StaticPrefs`, so the patch defines the pref as true by default.
Differential Revision: https://phabricator.services.mozilla.com/D37204
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Previously, popup widgets with empty bounds would not be hidden.
Non-popup GTK widgets with empty bounds would be hidden during ResizeClient().
Skipping the resize for popups is only appropriate when they are hidden.
Differential Revision: https://phabricator.services.mozilla.com/D17394
--HG--
extra : moz-landing-system : lando
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.
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando