This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
Before we use AudioContext's state as a hack to know the suspend status of window, but now we will prevent AudioContext from being suspended in the following patch.
So we need to add a chrome-only attribute to expose that to the test.
Differential Revision: https://phabricator.services.mozilla.com/D119838
Actually, APZ's zoomToRect doens't support position: fixed content. If so,
we use PresShell's scrollIntoView instead to scroll focused content if it
isn't visible.
Differential Revision: https://phabricator.services.mozilla.com/D117728
On a long press touch event we fire a contextmenu event and if the contextmenu
is opening, we fire a touchcancel event. Unfortunately we had been checking
the return value, nsEventStatus, from nsIWidget::DispatchInputEvent via
nsContentUtils::SendMouseEvent to tell whether the context menu is opening or
not. So, we unintentionally fire the touchcancel event if the context menu is
NOT going to be opened because of preventDefault() in a contextmenu event
listener in the content itself.
NOTE: The oparator<< for the new PreventDefaultResult enum will be used in
APZ logging code.
[1] https://searchfox.org/mozilla-central/rev/95c41d54c3fd65d51976d5188842a69b459a7589/mobile/android/actors/ContentDelegateChild.jsm#100
Differential Revision: https://phabricator.services.mozilla.com/D115963
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
Warn when some of the pre-conditions fail and such, so that it's easy to
see what's going wrong without having to use a debugger.
Remove some useless null-checks (we were dealing with null arguments
anyways, and the return value is never null).
Depends on D114078
Differential Revision: https://phabricator.services.mozilla.com/D114079
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
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 patch is plumbing to get a path and a flags word through from the content
process to the graphics process, to pass to `wr_api_start_capture_sequence`.
Differential Revision: https://phabricator.services.mozilla.com/D106229
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
Now, there are no users of this API. However,
`nsIWidget::SynthesizeNativeMouseMove()` is still used by `EventStateManager`.
Even though it's just redirected to `nsIWidget::SynthesizeNativeMouseEvent()`,
but it hides the native event message from `EventStateManager`. Therefore,
this patch keeps the widget API for now.
Differential Revision: https://phabricator.services.mozilla.com/D105762
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
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
In OOP iframes, we don't have desktop zoom value specifically in each iframe
documents, instead we have a transform matrix,
nsIWidget::WidgetToTopLevelWidgetTransform(), on each the __top__ level OOP
iframe document that the matrix includes the desktop zoom scale value along with
translations by ancestor scroll containers, ancestor CSS transforms, etc.
Note that if the document is not in OOP iframes, i.e. it's in the top level
content subtree, the transform, nsIWidget::WidgetToTopLevelWidgetTransform()
doesn't include the destktop zoom value, so for documents in the top level
content document subtree, ViewportUtils::DocumentRelativeLayoutToVisual applies
the desktop zoom value via PresShell::GetResolution().
Differential Revision: https://phabricator.services.mozilla.com/D102219
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
OneShotPostRefreshObserver works as the caller registers it, and
let it deletes itself via the DidRefresh method. The issue is that
DidRefresh is not guaranteed to run, and it'll leak PresShell
if it doesn't run.
This patch allows nsPresContext to store and release the last
registered OneShotPostRefreshObserver, and converted the existing
usage of OneShotPostRefreshObserver to use that. So instead of asking
OneShotPostRefreshObserver to delete itself, we now ask nsPresContext
to release it.
Differential Revision: https://phabricator.services.mozilla.com/D99939
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
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
When show virtual keyboard, we calls ZoomToFocusedInput to scroll to focused
element. But this method only consider single line control. It means that this
doesn't scroll better position when focused element is multiple such as
content editable. Because we use element rectangle foo zoom to rect.
So I would like to change this for <textarea> and contenteditable.
If <textarea> or contenteditable, we should use caret frame to scroll to
better position.
Differential Revision: https://phabricator.services.mozilla.com/D96374
This is a best-effort thing of course, but so is the rest of the
visibility threshold stuff in practice and this should be good enough.
Differential Revision: https://phabricator.services.mozilla.com/D98360
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
layout/base/tests/test_bug332655-1.html calls focus on an element, this triggers a call to zoomToFocusedInput. This can zoom the parent document of the test, the mochitest harness.
Then test layout/base/tests/test_bug667512.html runs. It ends by synthesizing a left arrow key and then a right arrow key. With the old scrollbar code this results in no scrolling because there is no layout scrolling that can be done either in the test or the parent document. With the new scrollbar code we can scroll the visual viewport using the keyboard so this scrolls the visual viewport of the test harness (because it got zoomed from a previous test).
The test harness being scrolled means that the synthesized click in the next test test_bug677878 can not hit its intended target.
Using the pref apz.zoom-to-focused-input.enabled to disable zoom to focused input in this directory does work to fix this, but I'm tired of doing that.
I think the proper fix here would be to disable scrolling/zooming of the test harness document. Since it's the root content document and it is not scrollable if not zoomed this is equivalent to disabling the zooming part of zoom to focused input (except for tests that open their own window). To test the zooming part of zoom to focused input we can use a test that opens it's own window: we have gfx/layers/apz/test/mochitest/test_group_zoomToFocusedInput.html for this.
We already have the pref formhelper.autozoom would seems like it would work for this purpose, except it is entangled with java stuff in mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoRuntimeSettings.java that I don't really understand that means setting the pref in mochitest.ini doesn't seem to take affect.
So I created a new pref we can use specifically for this purpose. Hopefully we can use it instead of fully disabling the zoom to focused input, so we more closely test what we ship.
Differential Revision: https://phabricator.services.mozilla.com/D95423
Even when the margins don't come from APZ, they are relative to
the visual viewport, and for the RCD-RSF there may be an offset
between the visual and layout viewports that they should be
translated by.
Bug 1669982 modified the call site in
CalculateAndSetDisplayPortMargins() to do this. This patch
refactors things such that all setters of the display port
do this if appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D93428
ZoomToFocusedInput calls ScrollContentIntoView() which may queue up
one or more main-thread scroll position updates that get sent to
APZ as part of the next transaction.
If such updates were produced, we want the ZoomToRect call to arrive
at APZ after the updates, otherwise the updates can cancel the
zoom animation that APZ starts in response to the ZoomToRect.
Differential Revision: https://phabricator.services.mozilla.com/D93898
ZoomToFocusedInput calls ScrollContentIntoView() which may queue up
one or more main-thread scroll position updates that get sent to
APZ as part of the next transaction.
If such updates were produced, we want the ZoomToRect call to arrive
at APZ after the updates, otherwise the updates can cancel the
zoom animation that APZ starts in response to the ZoomToRect.
Differential Revision: https://phabricator.services.mozilla.com/D93898
ZoomToFocusedInput calls ScrollContentIntoView() which may queue up
one or more main-thread scroll position updates that get sent to
APZ as part of the next transaction.
If such updates were produced, we want the ZoomToRect call to arrive
at APZ after the updates, otherwise the updates can cancel the
zoom animation that APZ starts in response to the ZoomToRect.
Differential Revision: https://phabricator.services.mozilla.com/D93898
This also changes all methods that use a pair of group/origin or a tuple of
suffix/group/origin input/output parameters to use a single GroupAndOrigin
resp. QuotaInfo struct input parameter or return value. Also, several types
having a pair or 3-tuple of such data members are changed to use these structs
instead.
Differential Revision: https://phabricator.services.mozilla.com/D91131
Where an adjustment (to reflect a delta between the APZ and layout
scroll offsets) is necessary, the inputs needed to compute the
adjustment are stored with the margins, and the adjustment is
applied at query time.
A couple of notes on this patch:
* Storing DisplayPortMargins::mLayoutOffset is probably unnecessary,
we should be able to just query the scroll frame's layout offset
when applying the margins.
* Some callers of DisplayPortMargins::WithNoAdjustment() may be
incorrect, in that they pass in margins that are relative to the
visual viewport but do not make a corresponding adjustment.
This is a pre-existing issue that this patch just makes clearer.
As this is a regression-prone area, this patch is careful to avoid
making any functional changes, leaving the above issues to be
addressed in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D92506
Along with a dependent struct DirectDrawInfo.
This allows nsImageRenderer.h and CanvasRenderingContext2D.h to
avoid including nsLayoutUtils.h.
For nsImageRenderer.h in particular, a forward declaration is
not sufficient as nsImageRenderer stores SurfaceFromElementResult
by value.
A couple of method definitions elsewhere are moved out of line
to keep things compiling without including nsLayoutUtils.h in
additional headers.
Differential Revision: https://phabricator.services.mozilla.com/D91684
Autocapitalize isn't applied if type is url, email or password. If these types,
truncate autocapitalize value in InputContext not to pass it to widget.
Differential Revision: https://phabricator.services.mozilla.com/D86676
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
Instead of getting/setting the size on the view manager on a fullscreen
change, this updates the code to get/set the size on the content viewer, which
internally sets the size on the view manager. Doing this ensures that the
content viewer size is updated prior to the reflow, which is required for
the MobileViewportManager to update its internal notions of size and to update
the visual viewport properly.
Differential Revision: https://phabricator.services.mozilla.com/D87161
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
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
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
One note about this solution: it includes the apz callback transform for the root scroll frame of the root content document, but no other apz callback transform that might be on an ancestor of the select element.
Differential Revision: https://phabricator.services.mozilla.com/D78026
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
We lifted this restriction because with bug 656036 it makes sense to zoom into a
focused input in a fixed subtree. But this causes undesired panning up.
We could conceivably fix it if needed, but for now preserve the previous
behavior of not panning nor zooming.
Differential Revision: https://phabricator.services.mozilla.com/D69946
--HG--
extra : moz-landing-system : lando
The tests don't have a reliable mechanism to wait for a potential zoom
animation to end, leading to flakiness due to a zoom animation form a previous
sub-case interfering with the current sub-case.
Differential Revision: https://phabricator.services.mozilla.com/D67522
--HG--
extra : moz-landing-system : lando
This refactoring:
* Removes the "avoid focusing a fixed subtree" condition, because it doesn't
make sense after bug 656036.
* Avoids keeping nsIFrame pointers across calls to ScrollContentIntoView(),
which can flush layout and thus is unsafe.
Differential Revision: https://phabricator.services.mozilla.com/D67220
--HG--
extra : moz-landing-system : lando
After removing Fennec-specific media control and audio focus related code, now no one is using `mediaSuspend` attribute, so we can remove it as well.
Differential Revision: https://phabricator.services.mozilla.com/D65402
--HG--
extra : moz-landing-system : lando
This is like screenPixelsPerCSSPixel, but does not take into account the
RDM override of the device pixel ratio. It is needed to be able to correctly
compute the translation from window coordinates to screen coordinates
from inside the RDM pane.
Differential Revision: https://phabricator.services.mozilla.com/D63751
--HG--
extra : moz-landing-system : lando
Per discussing with @hiro, we should add new method to get viewport-fit
instead of adding parameter of `nsIDOMWindowUtils.getViewportInfo`.
Depends on D55609
Differential Revision: https://phabricator.services.mozilla.com/D57397
--HG--
extra : moz-landing-system : lando
Although CssEnvironment is in Device of media query implementation, some code
creates CssEnvironment instance without Device. So I would like always to use it from Device of media query.
Differential Revision: https://phabricator.services.mozilla.com/D52506
--HG--
extra : moz-landing-system : lando
Now that we have UTF8String in the WebIDL, we can remove quite a few of the
conversions. Do that, and lift the remaining string conversions up as needed.
Also deindent Servo_ComputeColor while touching it.
Most of the remaining copies are because either bug 1606994, or because they're
WebIDL attributes that we still need to serialize back as UTF-16 (bug 1606995).
Differential Revision: https://phabricator.services.mozilla.com/D58687
--HG--
extra : moz-landing-system : lando
In particular, the ones where we transcode unconditionally atm (property names
and such).
There are others like cssText getters and setters which are a bit harder,
because I either need to rewrite all our serialization code to work with UTF8
(which is fine, but a lot of work), or teach webidl to have a setter that takes
UTF8String as input but returns DOMString as output (which is at best hacky).
Differential Revision: https://phabricator.services.mozilla.com/D58631
--HG--
extra : moz-landing-system : lando
`synthesizePlainDragAndDrop()` synthesizes drag events with `DataTransfer`
object which is set to `DragEvent.dataTransfer` of `dragstart` after starting
drag session explicitly. However, this causes
`EventStateManager::DoDefaltDragStart()` does not initialize `nsIDragService`
instance. Therefore, synthesized drag events cannot work with editor because
`DragEvent::GetMozSourceNode()` returns `nullptr` due to
`nsIDragSession::GetSourceNode()` returning `nullptr`.
On the other hand, synthesized drag events cannot use
`nsIDragService::InvodeDragSession()` normally because of hitting an assertion.
https://searchfox.org/mozilla-central/rev/690e903ef689a4eca335b96bd903580394864a1c/widget/nsBaseDragService.cpp#230-233
This patch does:
- mark drag events caused by synthesized mouse events as "synthesized for tests"
- make `synthesizePlainDragAndDrop()` stop using
`nsIDragService.startDragSession()`
- make `nsBaseDragService` initialize and start session even for synthesized
`dragstart` event
- make `synthesizePlainDragAndDrop()` stop synthesizing drag events with
`DataTransfer` object since it's normal behavior and it'll be initialized
with `nsIDragService::GetDataTransfer()`
- make `nsBaseDragService` store `effectAllowed` for the session only when
it's synthesized session because it's required at initializing synthesized
default `dropEffect` value of `dragenter`, `dragover`, `dragexit` and `drop`
events' `dataTransfer`
- make all tests which use `nsIDragService.startDragSession()` use new
API, `nsIDragService.startDragSessionForTests()` to initialize session's
`effectAllowed` value
- make `EventStateManager::PostHandleEvent()` set drag end point of the test
session to `eDrop` event's screen point
- make `synthesizePlainDragAndDrop()` set drag end point of the session if
it does not synthesize `drop` event because following `endDragSession()`
use it at dispatching `dragend` event on the source element
Additionally, this adds `dumpFunc` new param to `synthesizePlainDragAndDrop()`
because it's really useful to investigate the reason why requesting DnD isn't
performed as expected.
Differential Revision: https://phabricator.services.mozilla.com/D57425
--HG--
extra : moz-landing-system : lando
