The goal here is to hook up the ctrl+0 keyboard shortcut to reset the scaling
zoom applied by pinch gestures (on touchscreen or trackpad), in addition to
resetting the reflow zoom (aka full zoom). This patch also makes other mechanisms
to reset the reflow zoom (e.g. clicking on the "100%" label in the hamburger menu)
also reset scaling zoom, which I think makes sense for consistency.
Most of this patch is just plumbing, but I'm unfamiliar with these codepaths
so requesting review from relevant owners to make sure it's sane.
Differential Revision: https://phabricator.services.mozilla.com/D94624
The goal here is to hook up the ctrl+0 keyboard shortcut to reset the scaling
zoom applied by pinch gestures (on touchscreen or trackpad), in addition to
resetting the reflow zoom (aka full zoom). This patch also makes other mechanisms
to reset the reflow zoom (e.g. clicking on the "100%" label in the hamburger menu)
also reset scaling zoom, which I think makes sense for consistency.
Most of this patch is just plumbing, but I'm unfamiliar with these codepaths
so requesting review from relevant owners to make sure it's sane.
Differential Revision: https://phabricator.services.mozilla.com/D94624
This should make the optimization landed earlier in this bug apply for
some of the NotifyThemeChanged() calls in nsWindow.cpp which are causing
all the extra invalidations.
If we know that system colors/fonts didn't change, we can avoid doing a
bunch of reflow work and the patch from earlier in the bug can avoid
re-rasterizing images too.
Differential Revision: https://phabricator.services.mozilla.com/D94425
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
The current formulation is inconsistent. If you call it with ScrollableDirection::Either it goes into nsLayoutUtils::GetNearestScrollableFrame which will return the first scroll frame with a non-hidden overflow. If you call it with any other ScrollableDirection it calls nsLayoutUtils::GetNearestScrollableFrameForDirection which returns the first scrollframe it finds that has non-hidden overflow AND has at least one dev pixel of scroll range.
So remove that function and call nsLayoutUtils::GetNearestScrollableFrameForDirection directly. This is a slight change of behaviour but it seems desirable for all callers.
Differential Revision: https://phabricator.services.mozilla.com/D91236
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
We did not pass FLAG_HIGH_QUALITY_SCALING down to the document used to
rasterize the SVG to a surface, resulting in embedded raster images to
not use high quality downscaling.
Differential Revision: https://phabricator.services.mozilla.com/D56422
There's no need to put this in nsLayoutUtils since it's so closely bound
to presShell anyway. So we move it from being a static nsLayoutUtils function
that takes a PresShell pointer, to being a method on the PresShell itself.
Two functional changes here:
1. Don't run the MaybeReflowForInflationScreenSizeChange code unless the
visual viewport actually changes
2. Run the MaybeReflowForInflationScreenSizeChange if the visual viewport
is reset.
These functional changes can be logically thought of as "group the font-
inflation reflow stuff together with the other visual-viewport-triggered
reflow stuff".
Depends on D80040
Differential Revision: https://phabricator.services.mozilla.com/D80041
The current notification enumerates all windows and calls
SysColorChanged on them.
The current implementation of SysColorChanged is not quite sound, as it
really needs most if not all of what ThemeChanged does: SVGs can use
system colors, so we need to also invalidate the image cache for
example.
It's also not clear it deals correctly with propagating system color
changes to other documents.
In some cases we were even firing both theme changes and system color
changes at the same time. Unify this code paths.
Differential Revision: https://phabricator.services.mozilla.com/D76487
If we called PaintFrame for drawWindow or something other than painting to the widget the visual scroll update won't make it to the compositor, so don't clear it.
This doesn't fix anything specifically, just noticed it while reading code.
Differential Revision: https://phabricator.services.mozilla.com/D76781
Make it show the contents of style sheets (as it used to before Stylo)
and make it work in --disable-debug --enable-layout-debugger builds.
Differential Revision: https://phabricator.services.mozilla.com/D76640
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
Even in comm-central and BlueGriffon, `nsISelectionController::*ForDelete()`
are not used. Therefore, we can remove them safely.
Differential Revision: https://phabricator.services.mozilla.com/D72296
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
Users have much better, easier alternatives, like
DOMWindowUtils.{loadSheetUsingURIString,removeSheet}, which we use to
replace the only caller that exists in mozilla-central (the editor
element, which loads EditorOverride.css).
This allows to clean up the style system and editor. There are other
callers in comm-central, but it seems they can switch to DOMWindowUtils
trivially, as the DOMWindowUtils APIs also use the system principal and
thus they can load any URL.
I'll make sure to give them some time with the migration and/or help
out of course.
Differential Revision: https://phabricator.services.mozilla.com/D71263
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
