Compared to other platforms, on "printing" PDF files, Windows writes straight
to the destination path. This causes the mainthread to become less responsive
if the path is slow (e.g. Network drive over VPN).
This still causes a mainthread block at the time the file is moved, but:
- Brings Windows' behaviour in line with other platforms
- Avoids `PrintTargetPDF` becoming async, which is less meaningful on
other platforms
- Reduces the async site to one (i.e. moving to destination path)
Differential Revision: https://phabricator.services.mozilla.com/D163506
APZ now ensures that GetHandledResult() is Unhandled when appropriate,
so the widget code doesn't need to special-case eIgnore any more.
Differential Revision: https://phabricator.services.mozilla.com/D164585
This effectively backs out the fix for bug 1746336, while keeping the test
added in that bug (PanZoomControllerTest#touchActionWithWheelListener)
passing using a different fix approach (remembering the eager status
and using it in the computation of the delayed result).
Differential Revision: https://phabricator.services.mozilla.com/D164114
This is a modified version of Haik's patch D114133. It aims to fix the
issues that cause our macOS native fullscreen tests to fail. To accomplish
this, it does these things:
1) It clarifies that emulated fullscreen and native fullscreen are
distinct end states. You can transition to fullscreen using either
method, but from there you can only leave fullscreen. In other words you
can't go directly from emulated fullscreen to native fullscreen nor the
other way.
2) It captures the NSWindow delegate methods associated with a native
fullscreen transition, and uses these to trigger and update the
transition in and out of native fullscreen. It is still possible to
programmatically trigger a native fullscreen transition using
DoMakeFullscreen.
3) It correclty handles requests to change fullscreen while a fullscreen
transition is still in progress. If a contrary change is requested during
transition, then the transition is marked for reversion when it's
complete.
Notably, it does *not* attempt to send any kind of event when the native
fullscreen transition is complete. There is no event-based method for the
browser (or the test harness) to know when the transition is complete. The
test harness will typically check for the sizemode events, which are sent
when the fullscreen transition begins. If the test harness quickly toggles
fullscreen off again, then the transition will be marked for reversion,
and the test harness will detect the the end of fullscreen as soon as the
reverting transition begins.
Callers could get the nsCocoaWindow into the wrong state by requesting
native fullscreen, and then while the transition is happening, requesting
an exit of fullscreen and then requesting emulated fullscreen. This would
be really hard for a user to accomplish, and our test harness should be
waiting for sizemode events after each transition and so it won't request
fullscreen in rapid succession like that.
Differential Revision: https://phabricator.services.mozilla.com/D160097
Bug 1798242 did not cause a regression. Then it seems OK to try to enable video overlay without ZeroCopyNV12Texture with non-intel GPUs to release.
Differential Revision: https://phabricator.services.mozilla.com/D164634
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Two minor changes that otherwise might go unnoticed in the following
parts:
- AppWindow can't skip SetSize calls that match the current size. On
Linux a previous call might not have changed the size yet. If the
current call is skipped, the previous call can ultimately dictate the
resulting size.
- BrowserParent should not have to call UpdatePosition when receiving
new dimensions from BrowserChild. But HeadlessWidget needs to call
NotifyWindowMoved when moved.
Differential Revision: https://phabricator.services.mozilla.com/D160259
Nowadays, only the frontend code should pre-populate the nsIPrintSettings
objects with saved prefs (before passing them those objects to platform code).
We removed the InitPrintSettingsFromPrefs calls from the Windows and Linux
native dialog code, but apparently not the macOS code.
Differential Revision: https://phabricator.services.mozilla.com/D164709
Note: NSPagesAcross/NSPagesDown is internal API to Apple and is basically
unknown to the Internet. I discovered it by digging through printing structs in
a debugger while trying to find out how the pages-per-sheet information was
being communicated internally in Cocoa. However, after finding it, I see Google
knows about a grand total of 18 pages on the Internet that mention it, all as
part of debug info dumps. That's still helpful though, since it shows that
these two dictionary entries have been in use since at least 2008, giving some
confidence about backwards compatibility and that it will likely remain in use.
Related to these dictionary keys, Apple's official documentation claims that
there are similarly named keys called NSPrintPagesAcross/NSPrintPagesDown:
https://developer.apple.com/documentation/appkit/nsprintpagesacrosshttps://developer.apple.com/documentation/appkit/nsprintpagesdown
However, I couldn't get those to work, either to read values or to set values.
The references I could find to them on the Internet were in debug output and
people also stating they couldn't get them to work. I have to wonder if someone
at Apple changed the names at some point and forgot to update the
documentation?!
Finally, note that NSPrintPagesPerSheet is long deprecated and nowadays just
has a dummy value of "1" hardcoded.
https://developer.apple.com/documentation/appkit/nsprintpagespersheet
Differential Revision: https://phabricator.services.mozilla.com/D164317
Note: NSPagesAcross/NSPagesDown is internal API to Apple and is basically
unknown to the Internet. I discovered it by digging through printing structs in
a debugger while trying to find out how the pages-per-sheet information was
being communicated internally in Cocoa. However, after finding it, I see Google
knows about a grand total of 18 pages on the Internet that mention it, all as
part of debug info dumps. That's still helpful though, since it shows that
these two dictionary entries have been in use since at least 2008, giving some
confidence about backwards compatibility and that it will likely remain in use.
Related to these dictionary keys, Apple's official documentation claims that
there are similarly named keys called NSPrintPagesAcross/NSPrintPagesDown:
https://developer.apple.com/documentation/appkit/nsprintpagesacrosshttps://developer.apple.com/documentation/appkit/nsprintpagesdown
However, I couldn't get those to work, either to read values or to set values.
The references I could find to them on the Internet were in debug output and
people also stating they couldn't get them to work. I have to wonder if someone
at Apple changed the names at some point and forgot to update the
documentation?!
Finally, note that NSPrintPagesPerSheet is long deprecated and nowadays just
has a dummy value of "1" hardcoded.
https://developer.apple.com/documentation/appkit/nsprintpagespersheet
Differential Revision: https://phabricator.services.mozilla.com/D164317
Actually, we can get Android release version from JNI generator, so it is
unnecessary to use `AndroidBridge` to get it.
Also, this cleans up unused AndroidBridge functions.
Differential Revision: https://phabricator.services.mozilla.com/D164431
Bug 1796849 implemented proper non-native tooltips so that we can draw
them in mismatched themes in GTK. That uses the InfoBackground /
InfoText color pair, which is the right color pair.
However on macOS InfoBackground didn't have dark-mode support (while
InfoText did), causing contrast issues.
Differential Revision: https://phabricator.services.mozilla.com/D163022
I think this is a slightly better color and saves me from actually
making a decision over the options in comment 9 and so on.
I'll ask Firefox UX to take a look at comment 9 so that they can
evaluate and make a decision (and maybe tweaking our link colors), if we
want to change it.
Depends on D163402
Differential Revision: https://phabricator.services.mozilla.com/D163403
This is a micro-optimization to process switching. Often the paint delayes child process to send back information that it is ready to receive data from the parent process.
There are be other tiny issues like this too.
Differential Revision: https://phabricator.services.mozilla.com/D163789
The main issue is the confusion between mGdkWindow and the toplevel when
we draw with client decorations. Though something else broke since we
enabled them and now even with MOZ_GTK_TITLEBAR_DECORATION=system the
bug reproduces.
The thing that's supposed to hide the tooltip on nsXULTooltipListener is
the mouseout event handler, but without this fix we would upgrade the
eMouseExitFromWidget to a synthesized mouse move here:
https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/events/EventStateManager.cpp#721-732
Make leave-notify handling properly parallel to enter-notify in order to
properly notify gecko of the mouse leaving the window, thus fixing the
bug.
We also need to stop doing pointer grabs. Reasoning:
* We already don't do it on Wayland (see bug 1377084).
* The APIs we use are deprecated.
* The pointer grabs send spurious top-level leave/enter-notify pairs
which aren't detectable (the leave/enter event pair sent to the
toplevel window doesn't have the GDK_POINTER_{GRAB,UNGRAB} reasons).
* The code we had to avoid them (bug 369599) no longer works with CSD:
* The window gets hit even though it's behind other windows.
* The hit-test still returns true when hitting the window decorations.
So we're effectively eating virtually all useful leave-notify events,
which is obviously not great. Also gtk4 apps don't seem to have the same
pointer-grabbing on context menus etc.
Differential Revision: https://phabricator.services.mozilla.com/D163646
We need to return correct EGLWindow from moz_container_wayland_get_egl_window() with correct scale/size
and also keep the EGLWindow up to date. In this patch we do:
- Implement moz_container_wayland_egl_window_needs_size_update() and use it in nsWindow::SetEGLNativeWindowSize().
Avoid redundant moz_container_wayland_egl_window_set_size()/moz_container_wayland_set_scale_factor() calls as it may lead to resize callback calls to MESA.
- If wl_container::eglwindow is present, check its size/scale in moz_container_wayland_get_egl_window() and update size/scale if needed.
- Use nsIntSize single param instead of width/height pairs in some moz_container_* functions.
- Assert when gtk_widget_get_window(container) returns null.
Differential Revision: https://phabricator.services.mozilla.com/D163698
I thought of adding that border-y thing, but no other native menus have
them on Win11 at least (tried Explorer and Settings).
It should be doable tho, lmk if you insist.
Differential Revision: https://phabricator.services.mozilla.com/D163172
The main issue is the confusion between mGdkWindow and the toplevel when
we draw with client decorations. Though something else broke since we
enabled them and now even with MOZ_GTK_TITLEBAR_DECORATION=system the
bug reproduces.
The thing that's supposed to hide the tooltip on nsXULTooltipListener is
the mouseout event handler, but without this fix we would upgrade the
eMouseExitFromWidget to a synthesized mouse move here:
https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/events/EventStateManager.cpp#721-732
Make leave-notify handling properly parallel to enter-notify in order to
properly notify gecko of the mouse leaving the window, thus fixing the
bug.
Differential Revision: https://phabricator.services.mozilla.com/D163646
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Two minor changes that otherwise might go unnoticed in the following
parts:
- AppWindow can't skip SetSize calls that match the current size. On
Linux a previous call might not have changed the size yet. If the
current call is skipped, the previous call can ultimately dictate the
resulting size.
- BrowserParent should not have to call UpdatePosition when receiving
new dimensions from BrowserChild. But HeadlessWidget needs to call
NotifyWindowMoved when moved. HeadlessWidget no longer stays in
"maximized" size mode after being resized or moved.
Differential Revision: https://phabricator.services.mozilla.com/D160259
Much like we allow to do so with colors and ints/floats.
Read a string pref for the font name, and a few float/bools for
size/weight/italic, which is what our LookAndFeel back-end supports.
Depends on D163270
Differential Revision: https://phabricator.services.mozilla.com/D163271
And hide internal but used values. System fonts are not exposed in the
computed style so this should be fine.
If we need the old values for some obscure reason, it's trivial to alias
them to e.g., menu or so.
Differential Revision: https://phabricator.services.mozilla.com/D163269
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Two minor changes that otherwise might go unnoticed in the following
parts:
- AppWindow can't skip SetSize calls that match the current size. On
Linux a previous call might not have changed the size yet. If the
current call is skipped, the previous call can ultimately dictate the
resulting size.
- BrowserParent should not have to call UpdatePosition when receiving
new dimensions from BrowserChild. But HeadlessWidget needs to call
NotifyWindowMoved when moved. HeadlessWidget no longer stays in
"maximized" size mode after being resized or moved.
Differential Revision: https://phabricator.services.mozilla.com/D160259
Much like we allow to do so with colors and ints/floats.
Read a string pref for the font name, and a few float/bools for
size/weight/italic, which is what our LookAndFeel back-end supports.
Depends on D163270
Differential Revision: https://phabricator.services.mozilla.com/D163271
And hide internal but used values. System fonts are not exposed in the
computed style so this should be fine.
If we need the old values for some obscure reason, it's trivial to alias
them to e.g., menu or so.
Differential Revision: https://phabricator.services.mozilla.com/D163269
As discussed in the bug, we're not justified in expecting this assertion's
condition to hold up; it can be made to fail in mundane/unconcerning ways.
DONTBUILD because this doesn't affect behavior at all in opt builds, and it
doesn't affect debug build behavior in treeherder-relevant ways either.
Differential Revision: https://phabricator.services.mozilla.com/D163416
We can delete nsWindow but reference to it is kept by GtkCompositorWidget and nsWindow destructor may be called from Compositor thread where GtkCompositorWidget may be deleted.
Allow such scenario if nsWindow is already an empty shell and only nsWindow memory is released from Compositor thread.
Differential Revision: https://phabricator.services.mozilla.com/D163145
Now hal uses AR_STATE for screen orientation, so we should move it from
WinUtils.cpp to WinUtils.h for newer Windows 11 SDK.
Also, newer Windows SDK has to set WINVER to WIN8 to use auto rotation API.
Differential Revision: https://phabricator.services.mozilla.com/D163099
Since Windows tablet mode has a orientation lock API, this patch
implements orientation lock backend for Windows tablet mode.
`GetAutoRotationState` API recognizes whether orientation API is supported on
the device. So this fix uses this API to check orientation API capability.
Differential Revision: https://phabricator.services.mozilla.com/D162451
This fixes the snap layouts feature on Windows 11.
Instead of using a content attribute (which is somewhat expensive to
look up) use the default appearance and do this where we deal with other
appearance hacks (before building themed backgrounds).
Consolidate this inside a DealWithWindowsAppearanceHacks function along
with the glass stuff.
Differential Revision: https://phabricator.services.mozilla.com/D162757
This fixes bug 1799460 for good. You can test this on Win10 with
browser.display.windows.non_native_menus=0 or HCM, but same applies to
Win7/8.
The front-end sets their own sizes anyways, and when the windows sizes
are less than the ones the front-end sets, we see that bug.
This is rather annoying because, even though it's fixable (we can fix
the intrinsic sizing code in the web to deal with this properly), it's
probably not worth fixing, as no web-exposed widget has a min-widget
size other than scrollbars and internal form control parts.
Removing this code altogether just works, since as I said before the
front-end sizes the menu parts anyways, so enforcing a given size in C++
is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D162709
We used to provide links to the bug numbers but this was broken
somewhere along the way. Now it is provided the failure IDs from which
it can attempt to extract a bug number, as well as always display any
failure ID and message whenever possible.
Differential Revision: https://phabricator.services.mozilla.com/D162734
- Remove nsDragService::CreateURIList() and replace it by nsDragService::SourceDataGetUriList().
It reads all items from nsITransferable and put them to uri list.
If data drop is performed to another application which doesn't have access to internal data storages (mailbox:// for instance),
request download and save referenced items to /tmp directory.
- Implement SourceDataAppendURLItem() which read one item from nsITransferable and append it to uri list.
Download and store internal files in /tmp directory.
- Make CreateTempFile() to block native events processing. nsIOutputStream/nsIInputStream read and write operations run
event loop and can abort D&D operation before we write all data to /tmp. Use nsAppShell to block native event processing
during read/write to prevent it.
Differential Revision: https://phabricator.services.mozilla.com/D162473
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
There's a bug (bug 1800022) that wheel event listeners in the browser process
badly interact with overscroll even so we'd avoid the bug here.
Differential Revision: https://phabricator.services.mozilla.com/D161752
Otherwise prefs set in the previous test case will persist. In fact
some of test cases were lacking "browser.swipe.navigation-icon-move-distance".
Differential Revision: https://phabricator.services.mozilla.com/D161751
One thing to note is that if the user shrinks this number we won't reclaim any memory - this is because I wanted to avoid doing any more work than necessary when we're logging messages. Let me know if you think this is a problem!
Differential Revision: https://phabricator.services.mozilla.com/D161156
At :handyman's suggestion, just removing the messages when we get a WM_DESTROY message works great and is way less complicated than the previous version of this :-)
Differential Revision: https://phabricator.services.mozilla.com/D161155
This is the list of messages that handyman and rkraesig suggested.
Since we're recording WM_GETMINMAXINFO, we now have better logging for that message.
Differential Revision: https://phabricator.services.mozilla.com/D161150
This is helpful for the normal event log, and also necessary since we want to group the messages up by window in the about page.
Differential Revision: https://phabricator.services.mozilla.com/D161149
The change disables ZeroCopyNV12Texture for checking if the video overlay works without ZeroCopyNV12Texture with non-intel GPU.
For now, on release, ZeroCopyNV12Texture is not enabled with non-intel GPUs. It blocks to enable video overlay with non-intel GPUs. Then it seems better to enable video overlay with non-intel GPUs on release without ZeroCopyNV12Texture if possible.
Differential Revision: https://phabricator.services.mozilla.com/D160744
One thing to note is that if the user shrinks this number we won't reclaim any memory - this is because I wanted to avoid doing any more work than necessary when we're logging messages. Let me know if you think this is a problem!
Differential Revision: https://phabricator.services.mozilla.com/D161156
At :handyman's suggestion, just removing the messages when we get a WM_DESTROY message works great and is way less complicated than the previous version of this :-)
Differential Revision: https://phabricator.services.mozilla.com/D161155
This is the list of messages that handyman and rkraesig suggested.
Since we're recording WM_GETMINMAXINFO, we now have better logging for that message.
Differential Revision: https://phabricator.services.mozilla.com/D161150
This is helpful for the normal event log, and also necessary since we want to group the messages up by window in the about page.
Differential Revision: https://phabricator.services.mozilla.com/D161149
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
There's a bug (bug 1800022) that wheel event listeners in the browser process
badly interact with overscroll even so we'd avoid the bug here.
Differential Revision: https://phabricator.services.mozilla.com/D161752
Otherwise prefs set in the previous test case will persist. In fact
some of test cases were lacking "browser.swipe.navigation-icon-move-distance".
Differential Revision: https://phabricator.services.mozilla.com/D161751
I don't have time to dig into them right now so disable there for now.
I could repro the flickering on Arch Linux, but I couldn't repro the
incorrectly-transparent popup or the incorrectly-open extension popup...
Differential Revision: https://phabricator.services.mozilla.com/D162240
This restores the previous behavior in a somewhat more principled way.
The extensions code is still broken in multi-monitor cases, but that's a
more complicated fix.
Differential Revision: https://phabricator.services.mozilla.com/D161997
When minimizing a fullscreen window, frame state is kept with
mFullscreenMode = true but mSizeMode = nsSizeMode_Minimized.
Calling EnsureSizeMode(nsSizeMode_Fullscreen) in this state would call
EnsureFullscreenMode(true), but that'd bail out without actually
setting the fullscreen sizemode, causing confusion.
Before the regressing patch that was papered over because
nsSizeMode_Fullscreen was passed explicitly to OnSizeModeChange(), but
the underlying state was already wrong before my patch.
Add some comments and documentation to the fullscreen-relevant members,
since initially I was rather confused about this code.
Differential Revision: https://phabricator.services.mozilla.com/D161982
This patch does **not** make `ContentEventHandler` return consistent rect
for invisible text node, however, it should be okay for now because users
cannot put caret into invisible text node and cannot type text into it.
For avoiding the warning spam of `ContentCacheInChild` in automated tests,
`ContentEventHandler::OnQueryTextRectArray` shouldn't give it up correcting
character rects in invisible text nodes. And as mentioned above, using
similar rects to visible character around there is okay. Therefore, this
patch makes `OnQueryTextRectArray` fills invisible text rects with caret
rect before following visible character if they are followed by visible
characters. Otherwise, i.e., if invisible text rects are the last things
in the range, make it use caret rect after the last visible character.
Note that if the range is completely in invisible nodes, the value will be
computed in the fallback part of the method. It still has issues, but it
does not happen so many times in the automated tests. Therefore, this patch
does not treat the case.
Differential Revision: https://phabricator.services.mozilla.com/D160593
David Shin
Botond Ballo
Brad Werth
Lee Salzman
Matthias Camenzind
Nika Layzell
Tom Schuster
sotaro
Cosmin Sabou
Edgar Chen
stransky
Jonathan Watt
Tom Schuster
Butkovits Atila
Makoto Kato
Emilio Cobos Álvarez
Olli Pettay
Daniel Baker
Cristian Tuns
az
Hiroyuki Ikezoe
Iulian Moraru
Sandor Molnar
Zach Hoffman
Ryan VanderMeulen
Manuel Bucher
Martin Robinson
Csoregi Natalia
Andreas Pehrson
Marian-Vasile Laza
Daniel Holbert
Zach Hoffman
Chris Martin
Barret Rennie
Stanca Serban
Andrew Osmond
Greg Stoll
Mark Banner
Florian Queze
Masayuki Nakano