Currently the test intermittently fails without firing additional touchstart/touchend, but scroll event still fires. This can happen if the previous swiping caused fling and it's still ongoing when a new swipe starts.
The ideal fix would be to detect the end of fling but there currently is no good way to do that. Instead this patch tries setting higher value for `apz.fling_stopped_threshold` to prevent flings from happening.
Differential Revision: https://phabricator.services.mozilla.com/D109684
So Element could decide how focus should be handled if accesskey shouldn't cause
activation, e.g. label element would forward focus to control element.
This could make behavior saner a bit, though there is still something we could
improve, e.g. if the control element doesn't have same accesskey, we are unable
to cycle to the next one in order while pressing same accesskey again.
But this is still better than stuck somewhere if label element is not focusable.
Differential Revision: https://phabricator.services.mozilla.com/D109067
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
`AutoScrollParent` starts autoscroll even if the requested tab has already
been in background tab. In this case, it does not make sense to start
autoscrolling in new foreground window since it may not be scrollable.
Additionally, our `mousedown` event default action activates the DOM window,
but in the DuckDuckGo's case, focus shouldn't be backed to the clicked tab.
Differential Revision: https://phabricator.services.mozilla.com/D106590
Chrome behaves like this:
1. When user starts autoscroll with a middle click, `mousedown` and `mouseup`
are fired, but `auxclick` nor `paste` event is not fired.
2. When user ends autoscroll with a left click, only `mouseup` event is fired.
I.e, `mousedown` nor `click` event is not fired.
3. When user ends autoscroll with a middle click, only `mouseup` event is fired.
I.e., `mousedown`, `auxclick` nor `paste` events is not fired.
4. When user ends autoscroll with a right click, `mouseup` and `contextmenu`
events are fired, but `mousedown` and `auxclick` events are not fired.
This patch emulates these Chrome's behavior as far as possible. However,
unfortunately, we cannot do exactly same behavior without some big patches
because each widget (`nsWindow` or `nsChildView`) discards a mouse event
which rolled up a widget before dispatching it into the DOM. Therefore,
for now, this patch does not fix the following issues:
1. `mousedown` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the secondary button or on any
buttons on Linux.
2. `mouseup` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the primary button macOS.
3. `click` event and `auxclick` events are fired when clicking outside the
autoscroller with the secondary button.
So, the middle button `click`/`auxclick` events and `paste` event which is
reported to the bug won't be fired with this patch. I'll file follow up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104652
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Note that this removes `window.ondeviceproximity` and `window.onuserproximity` which unexpectedly have been exposed unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D109160
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
This test synthesizes touch input only in continuous way via dragging functions, so theoretically it should never trigger InjectTouchInput() 100ms timeout issue.
Depends on D109158
Differential Revision: https://phabricator.services.mozilla.com/D109159
For that, we make accessibility.mouse_focuses_formcontrol a static pref,
and make it work in all platforms because it's simpler and allows to
test mac-specific things on other platforms more easily.
Differential Revision: https://phabricator.services.mozilla.com/D109006
This aligns Mac's focus model with other platforms. Matches Chromium, but not
Safari.
Reasons why I think it's worth making this change:
* Consistency with all other platforms.
* Makes the :focus-visible implementation more useful.
* Fixes focus navigation after e.g. clicking a button.
* Shouldn't cause a lot more outlines to show up (at least not by default).
An example of the second point:
data:text/html,<button onclick="this.nextElementSibling.focus()">Click</button><button>Imagine I'm a dialog close button or something</button>
In non-macOS platforms, we won't show an outline for the button in that case,
which matches the developer expectations (links below). We don't show the
outline because the focus comes from an element that has been focused by mouse
(and thus didn't show an outline). But on macOS that doesn't work, because the
button is not focused.
For completeness, the actual heuristics for :focus-visible may change a bit as
a result of the discussions in:
* https://github.com/w3c/csswg-drafts/issues/5885
* https://github.com/web-platform-tests/wpt/pull/27806
But it's not clear to me how to best define this so it works on the macOS focus
model.
An example of the third point:
data:text/html,<input type=text><input type=submit><input type=text>
On Safari and Chrome (and Firefox on non-macOS platforms), clicking the button,
then pressing tab, goes to the input on the right. In Firefox on macOS it
doesn't because the button doesn't gain focus nor is selectable.
Differential Revision: https://phabricator.services.mozilla.com/D108808
These tests are too annoying to restructure completely, so I'm just
doing a local inlining of the function here.
Depends on D108438
Differential Revision: https://phabricator.services.mozilla.com/D108439
This test case doesn't generate body element and isn't general case. Actually
since we don't manage current IME focus on IMEStateManager, we shouldn't notify
IMEContext of widget.
Differential Revision: https://phabricator.services.mozilla.com/D108366
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
E.g., comment node is an invisible data node, and it's not handled by
`HTMLEditor` nor `ContentEventHandler`. Therefore, `IMEContentObserver`
should ignore invisible data nodes, which are not derived from `dom::Text`.
Differential Revision: https://phabricator.services.mozilla.com/D107590
Kagami Sascha Rosylight
Butkovits Atila
Edgar Chen
Simon Giesecke
Masayuki Nakano
Tom Schuster
Kartikaya Gupta
Kris Maglione
Bogdan Tara
Cosmin Sabou
Emilio Cobos Álvarez
Sean Feng
Florian Quèze
Makoto Kato
Jonathan Kew
Alexandru Michis
Brindusan Cristian
Andreea Pavel
Micah Tigley
Csoregi Natalia