Actually software keyboard is opened by the following situations.
- Click event in editor
- Get new focus event.
Ace editor has small <textarea> element to handles some input events.
When clicking editable-like area (but this isn't ediable on Ace editor),
mousedown handler calls `event.preventDefault()` then set focus to
<textarea> element. So editor doesn't get click event and focus is still
keep in <textarea> element. At finally, we cannot open software keyboard
again since focus isn't changed.
So even if focus isn't changed, we should call SetInputContext to open
software keyboard.
Also, actually we doesn't have generic test code for notification of
software keyboard change (bug 1670539). I will add the test by bug 1670539.
Differential Revision: https://phabricator.services.mozilla.com/D93326
Add `static mozilla::MarkerSchemaWriter MarkerTypeDisplay()` for each existing marker type.
Because all markers of a given type now must have the same payload and display schema, the DOM event marker has changed from type=tracing with category=DOMEvent, to its own type=DOMEvent, which is now accepted on the front-end.
Based on c9692715f2/src/profile-logic/marker-schema.js
Differential Revision: https://phabricator.services.mozilla.com/D90658
Full zoom in the child process won't be applied to the cursor rect, so
undo it before checking to consider the actual rect that will be used.
Differential Revision: https://phabricator.services.mozilla.com/D93329
when there is no composition, `IMEStateManager::HandleSelectionEvent()` calls
`TextComposition::HandleSelectionEvent()` with `BrowserParent` which is
retrieved from `aEventTargetContent` which is focused content in the main
process. This means that `eSetSelection` event is handled in root document
of the focused tab when there is no composition. However, following composition
events will go to focused `BrowserParent`, i.e., if an OOP iframe has focus
in the tab, `eSetSelection` event won't be handled in it. Therefore, IME
always fails to replace existing text with new composition.
This patch makes both `IMEStateManager::HandleSelectionEvent()` and
`PresShell::EventHandler::DispatchEventToDOM()` use
`IMEStateManager::GetActiveBrowserParent()` for sending both `eSetSelection`
and composition events to same process. Additionally, this patch make
`IMEStateManager::GetActiveBrowserParent()` returns
`IMEStateManager::sFocusedIMEBrowserParent` when it's set to non-nullptr
because native IME tries to modify the editor which enabled IME context.
On the other hand, for making the behavior safer, we should make
`eCompositionStart` event have replacing range optionally. I filed
bug 1669907 to change the design, but it requires several non-tiny patches.
Once we fix it, we can write automated tests for this simply, but without
the fix, I need to write too many lines with low level API, and it becomes
unnecessary after fixing the bug. Therefore, I give up to write a test
for this for now.
Differential Revision: https://phabricator.services.mozilla.com/D93053
When `HTMLEditor` instances are destroyed, I'd like to collect how much
instances are worked with `beforeinput` event listeners. Before adding such
telemetry probe, this patch adds methods to set/get whether a `beforeinput`
event listener has had added or not to `nsPIDOMWindowInner`.
Differential Revision: https://phabricator.services.mozilla.com/D92546
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 audio/video controls element has touch listeners on the scrubber, which
steals events when we don't want it to. So let's ignore those listeners.
Ignoring system group listeners for the purposes of event retargeting seems
reasonable in the general case, because those listeners are coming from the
browser itself. If we're relying on the event retargeting to make those browser
elements easy to hit, then we should not be doing that and instead just make
them bigger.
Test coverage for this change is provided by the android-components tests that
failed in bug 1668112. The next patch re-enables touch event retargeting and
exercises this code in the context of those tests.
Depends on D92436
Differential Revision: https://phabricator.services.mozilla.com/D92437
We don't need to flush before dispatching the event because we know that
if the values we cared about changed, then we'd get another event.
Differential Revision: https://phabricator.services.mozilla.com/D92444
This is part of the Markers 2.0 work. This payload proved to be a bit ambiguous
when moving to the new marker schema, so it requires an upgrader.
The test is included as the following commit.
Differential Revision: https://phabricator.services.mozilla.com/D92456
The telemetry probe was added in bug 1506434, and it's not necessary anymore
because of the event in the default group was completely disabled in
bug 1288640 (Gecko 65).
Therefore, we can get rid of the pref, and we can take back a room for a
bool member in `nsPIDOMWindowInner` for new telemetry probes which need
to know whether a specific event listener has been added or not.
Depends on D92395
Differential Revision: https://phabricator.services.mozilla.com/D92397
- onSVGZoom is gone and we no longer dispatch it.
- we've never dispatched SVGUnload or SVGResize events and if we did implement these they would be unload and resize events now.
Differential Revision: https://phabricator.services.mozilla.com/D92381
This makes it clearer where marker-type-specific payload arguments start, just after the marker type object.
Also improved the main API documentation.
Differential Revision: https://phabricator.services.mozilla.com/D91681
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
This makes it clearer where marker-type-specific payload arguments start, just after the marker type object.
Also improved the main API documentation.
Differential Revision: https://phabricator.services.mozilla.com/D91681
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The only thing in nsIFrame.h that was using it was the implementation
of a templated method, which could be moved to nsIFrameInlines.h.
Depends on D91504
Differential Revision: https://phabricator.services.mozilla.com/D91505
This patch covers thw low-hanging fruit: headers that either don't use
nsLayoutUtils.h at all, or where only method implementations that can
easily be moved to the .cpp file use it.
Differential Revision: https://phabricator.services.mozilla.com/D91504
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
Now requesting/releasing pointer lock in content process will send IPC to let
parent process know which content process request a lock, so parent process
could dispatch mouse event to the right content process. And if there is already
a content proess had a lock, parent process will reject lock request from other
content proesses.
Differential Revision: https://phabricator.services.mozilla.com/D90313
Now requesting/releasing pointer lock in content process will send IPC to let
parent process know which content process request a lock, so parent process
could dispatch mouse event to the right content process. And if there is already
a content proess had a lock, parent process will reject lock request from other
content proesses.
Differential Revision: https://phabricator.services.mozilla.com/D90313
There is only one call site, so I believe it's best to have the marker type there.
I think it's cleaner this way, this marker type doesn't need to be present in a header shared by all users of the profiler.
The only downside is that we cannot unit-test this particular marker type automatically anymore, but I don't think it's strictly needed:
- There are still plenty of tests checking that generic marker types work end-to-end, so we can have some confidence this specific one can do its job.
- If it somehow started to fail, either it would be quickly found that it breaks the front-end, or it wouldn't have any visible effect in which case it's not a big issue.
Follow-up bug 1665810 will instead add a higher-level xpcshell test or mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D90185
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
CLOSED TREE
Backed out changeset d3d67293f115 (bug 1623413)
Backed out changeset 75ed1b8a5c67 (bug 1623413)
Backed out changeset 0eef32d6a454 (bug 1623413)
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
There are three cases,
- Move to inner OOP frame.
- Move to outer OOP frame.
- Move to an OOP frame that is in different sub-tree.
We could use common BrowserParent ancestor to determine which case is and
dispatch MouseExitFromWidget event with proper ExitFrom type.
Depends on D84748
Differential Revision: https://phabricator.services.mozilla.com/D84761
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
There are three cases,
- Move to inner OOP frame.
- Move to outer OOP frame.
- Move to an OOP frame that is in different sub-tree.
We could use common BrowserParent ancestor to determine which case is and
dispatch MouseExitFromWidget event with proper ExitFrom type.
Differential Revision: https://phabricator.services.mozilla.com/D84761
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
By moving the few things that need to be exposed to other components
to APZPublicUtils.h, APZUtils.h becomes much less widely included
(and thus changing it triggers a quicker recompile) while retaining
most of its utilities.
Differential Revision: https://phabricator.services.mozilla.com/D87404
synthesizeNativeMouseEvent in apz_test_native_event_utils.js doesn't work on xorigin tests give that it would try to access window.top which is a cross-origin window.
Differential Revision: https://phabricator.services.mozilla.com/D87350
Wait for iframe loaded before starting the tests, otherwise, the `synthesizeMouse` might fail due to `nsPresShell` isn't yet finishing initializing and `nsPresShell::GetRootFrame` would returns `nullptr`.
Differential Revision: https://phabricator.services.mozilla.com/D87201
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
This is pretty much a backout of bug 1638314. The probes have served their
purpose and there's no need to renew them, so we can just remove them.
Differential Revision: https://phabricator.services.mozilla.com/D86838
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
Actually, altough TSF and IMEStateManager have the logging for InputContext,
I would like to use common logging code using `ToString.h`.
Differential Revision: https://phabricator.services.mozilla.com/D84287
-moz-inert CSS property reflects inert subtrees concept and can be used to implement HTML:dialog element and HTML:inert attribute
Differential Revision: https://phabricator.services.mozilla.com/D81701
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
Before these changes, ContentChild.h was the #9 most expensive header to include:
217505 ms: /home/simon/work/fuzzy/obj-x86_64-pc-linux-gnu-optimized/dist/include/mozilla/dom/ContentChild.h (included 105 times, avg 2071 ms)
After these changes, it is no longer among the top 30 most expensive headers.
Some missing includes in other files are added along.
Differential Revision: https://phabricator.services.mozilla.com/D83049
Same as the previous patch, it can be split to computation part and
modifying the DOM tree part. Then, the former can be in `TextFragmentData`
and the latter can be done by the caller which is only
`WSRunObject::InsertText()`.
Depends on D82699
Differential Revision: https://phabricator.services.mozilla.com/D82700
Current implementation of Blink and WebKit is that enter key is dispatched
even if `enterkeyhint` is `next`. If no enterkeyhint, Gecko and Blink infer
this type from `<form>` and `<input>` element.
If this key is set as "next" by inference, Blink doesn't dispatch key event
then sets focus to next element, and Gecko dispatches `Tab` key to set focus
to next element.
So if action hint is "next" by inference, we would like to change to another
type "maybenext".
Differential Revision: https://phabricator.services.mozilla.com/D79645
Set enterkeyhint to `InputContext.mActionHint`. Although it is used by
`moz_action` attribute, enterkeyhint is standardized version of this.
New logic is the following.
1. Read `enterkeyhint` that is from editing host
2. Read `moz_action` on `<input>` element if no `enterkeyhint`
3. If both is nothing, we infer this value from the `<form>`.
Differential Revision: https://phabricator.services.mozilla.com/D79644
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
Content process could also contain a remote target after fission, we need to do
same check in content process, like what we do in parent process for e10s.
Depends on D79441
Differential Revision: https://phabricator.services.mozilla.com/D79917
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This patch is a fairly mechanical conversion. The old `nullptr` gets converted
to ScrollOrigin::NotSpecified, and all the other possible values get corresponding
values in the new ScrollOrigin enum. A few switch statements are introduced to
clean up big if statements, but other than that, additional cleanups will happen
in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D78438
The test relied on synthesized mousemove event from refresh driver to generate
corresponding mouseenter/mouseleave event, but it would have possible racing
given that we don't know when the mousemove would be synthesized, especially
in opt build. So synthesize mousemove event from test script explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D77935
Adds an |aChromeOnlyDispatch| flag to DispatchCustomEvent to decide whether
to call DispatchTrustEvent or DispatchEventOnlyToChrome.
The following chrome-only events are dispatched with DispatchCustomEvent and now
make use of the flag:
- DOMWindowClose
- fullscreen / willenterfullscreen / willexitfullscreen
- occlusionstatechange
- resolutionchange
- XULAlertClose
and the following were previously dispatched with DispatchTrustedEvent and now
use DispatchEventOnlyToChrome:
- MozBeforeInitialXULLayout
- MozMouseScrollFailed / MozMouseScrollTransactionTimeout
- MozPaintWait / MozPaintWaitFinished
- MozPerformDelayedBlur
- all events fired by APZCCallbackHelper::NotifyMozMouseScrollEvent
Differential Revision: https://phabricator.services.mozilla.com/D76723
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
I removed some outlines in gtk which causes some repaints not to show
up. However I think this test should be simplified a bit instead.
When this test landed in bug 426082, snapshots and such were the only
way to test this because it was a widget hack, effectively. Nowadays,
that "forward hover and active state from label to labeled element"
happens at the event state manager level, and thus we can test it much
more easily using simple selector-matching.
Differential Revision: https://phabricator.services.mozilla.com/D76602
Firing eMouseExitFromWidget means we are leaving a specific remote target, then
we should not update sLastMouseRemoteTarget. Otherwise the subsequent event
might trigger sending eMouseExitFromWidget again.
Differential Revision: https://phabricator.services.mozilla.com/D75916
This method can be and is used by derived classes as well as DOMEventTargetHelper
itself, so it does not need to be "Internal".
Differential Revision: https://phabricator.services.mozilla.com/D75246
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
If a mouse is over a remote target A, and then moves to remote target B,
we'd deliver the event directly to remote target B after the moving, A would
never get notified that the mouse left. And A would synthesizes mousemove event
on an incorrect point which then generates an unexpected mouseleave.
Differential Revision: https://phabricator.services.mozilla.com/D67408
This seems to come from bug 618907, which seems to be a hack-around code
that went away in bug 1595435.
If we open a window on mousedown such as it gains focus before this code
runs, we just steal the focus from it, which is undesired.
Also remove the test for bug 799299. It doesn't work anyways if the
browser is remote (this test only runs on non-e10s mode), and this
unifies the behavior with e10s and with content (see attached test-case,
which doesn't change behavior with and without my patch).
Differential Revision: https://phabricator.services.mozilla.com/D73901
This seems to come from bug 618907, which seems to be a hack-around code
that went away in bug 1595435.
If we open a window on mousedown such as it gains focus before this code
runs, we just steal the focus from it, which is undesired.
Also remove the test for bug 799299. It doesn't work anyways if the
browser is remote (this test only runs on non-e10s mode), and this
unifies the behavior with e10s and with content (see attached test-case,
which doesn't change behavior with and without my patch).
Differential Revision: https://phabricator.services.mozilla.com/D73901
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
After the recent simplifications to the zoom code, they only take care
of forwarding the enlarge / decrease zoom messages.
We can do that via PBrowser instead, and get rid of the actors. We can
also remove ZoomChangeUsingMouseWheel. Zooming with the mouse wheel will
end up in a *ZoomChange event anyways, and the only consumer already
listened for them.
Differential Revision: https://phabricator.services.mozilla.com/D73175
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
We currently pass nsFrameLoader to DispatchCrossProcessEvent and then try to get
BrowserParent from nsFrameLoader, but the call site actually ensures the
passed nsFrameLoader is a remote target that could get BrowserParent on it.
So we could simplify this by passing BrowserParent to DispatchCrossProcessEvent
and also could get rid of unnecessary conversion code in
EventStateManager::HandleCrossProcessEvent.
Differential Revision: https://phabricator.services.mozilla.com/D73037
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
According to [*1], Android's text control now supports ctrl+backspace and
ctrl+delete shortcut. So we should support it since Chrome already have this.
*1 f2b233d44c
Differential Revision: https://phabricator.services.mozilla.com/D71736
We should always do this, otherwise stuff may not end up being visible which is
not acceptable for focus navigation.
Differential Revision: https://phabricator.services.mozilla.com/D70541
--HG--
extra : moz-landing-system : lando
For the usecases in dom/file, I'm not so sure how to get the global at
callsites, so I let aIsSystemPrincipal and aCrossOriginIsolated to be false for
now.
Differential Revision: https://phabricator.services.mozilla.com/D63905
--HG--
extra : moz-landing-system : lando
Actually, current code gets type attribute by `GetAttr`, But this cannot get
valid value. If no type attribute, `mHTMLInputType` will be empty. So if type
has invalid value, we should return `text` value instead.
Depends on D69349
Differential Revision: https://phabricator.services.mozilla.com/D69350
--HG--
extra : moz-landing-system : lando
Actually inputmode attribute exposes <input> element only, current WHATWG spec
allows all HTML element. So inputmode in input context should be always set.
Also, if using contenteditable, this attribute is only used on editing host when
using other browsers (Blink and Webkit). It is
https://github.com/whatwg/html/issues/5322.
Depends on D69348
Differential Revision: https://phabricator.services.mozilla.com/D69349
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
Johann Hofmann
Makoto Kato
Gerald Squelart
Masayuki Nakano
Edgar Chen
Emilio Cobos Álvarez
Narcis Beleuzu
Kartikaya Gupta
Greg Tatum
longsonr
Timothy Nikkel
Jonathan Kew
Bogdan Tara
Botond Ballo
Simon Giesecke
Anny Gakhokidze
Mirko Brodesser
Noemi Erli
Kagami Sascha Rosylight
Mihai Alexandru Michis
Nathan Froyd
Henri Sivonen
Cosmin Sabou
Andreas Farre
Sean Feng
Razvan Maries
Butkovits Atila
Mats Palmgren
Alexander Surkov
tkhan
Cameron McCormack
Hiroyuki Ikezoe
Kagami Sascha Rosylight
Kris Maglione
Alexis Beingessner
Olli Pettay
Kashav Madan
Micah Tigley
Peter Van der Beken
Karl Tomlinson
Denis Palmeiro
Jonathan Watt
Dorel Luca
Csoregi Natalia
Coroiu Cristina
Gijs Kruitbosch
Jon Coppeard
Tom Tung
Brian Grinstead
Eric Rahm