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
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
On Wayland, it is not possible to warp the pointer.
To use the appropriate protocols, new IPC messages were added for supporting
a platform's native pointer locking mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D102114
This required more refactoring so it seemed sensible to split it out. GTK
doesn't seem to provide an API for scaled cursors so we get pixelated cursors
instead.
Differential Revision: https://phabricator.services.mozilla.com/D112676
This removes some sketchy non-caching of cursors on windows while at it,
now that plugins are gone, but otherwise shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D112475
Include the scaling factor in the SizeConstraints struct so that widgets can
correctly constrain their width and height when the widget's scaling factor
differs from the nsPresContext.
Differential Revision: https://phabricator.services.mozilla.com/D109265
Creating an event with type NSEventTypeSmartMagnify does not work with either NSEvent mouseEventWithType or NSEvent otherEventWithType (they both hit an assert in the appkit code). So the best we can do is call the same function.
Differential Revision: https://phabricator.services.mozilla.com/D107792
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
Surprisingly, they don't take modifiers, and
`nsIWidget::SynthesizeNativeMouseEvent()` which are implementations of
`nsIDOMWindowUtils::SendNativeMouseEvent()` treat given modifier flags
are native's ones, and handle modifiers only on macOS. Therefore, this
patch makes them handle native modifiers of Gecko.
Unfortunately, I'm not so familiar with Android API, and in the short
term, I don't need the support on Android. Therefore, this patch just
adds a TODO comment on Android widget.
Additionally, we don't have a simple way to set modifier only while
posting a mouse input on Windows too. It requires complicated code.
Therefore, I don't add the support for it on Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D105758
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
Because we create our initial window much earlier, we do not receive the
initial activation and focus messages in the same way. Accordingly, we
need to refocus the window once everything is properly set up to handle
it.
Regarding testing, the intent is that this will be covered by existing
tests, since this is not intended to be a behavioral change for window
focus. It is not covered by tests currently only because the skele UI
is disabled by default.
Depends on D90467
Differential Revision: https://phabricator.services.mozilla.com/D90607
No longer called. This was done as an optimization for OOP iframes, but
it affects the scrollport so it's clearly not sound (the visible rect
shouldn't affect the layout scroll port).
If very tall OOP iframes are a problem somehow, it's something that we
need to deal with in another place. It was, in fact, removed for
top-level remote iframes because of bug 1554861 and other regressions.
Depends on D80731
Differential Revision: https://phabricator.services.mozilla.com/D80732
Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.
This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.
With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.
Differential Revision: https://phabricator.services.mozilla.com/D75419