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
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
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 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
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
Otherwise the user can select, but if you're in an iframe the iframe won't be
correctly focused.
This also matches other browsers, see:
data:text/html,<input autofocus><input disabled value=abc>
data:text/html,<input autofocus><button disabled>Foo</button>
And so on. This effectively undoes bug 375008. We could make this more targeted
somehow, but I don't think it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D67597
--HG--
extra : moz-landing-system : lando
The patch adds similar to mousemove compression on IPC layer.
https://searchfox.org/mozilla-central/rev/49ed791eec93335abfe6c2880f84c324e73e47e6/dom/ipc/PBrowser.ipdl#764-774
Touch events can't be compressed all the time, because each touch event
may contain changes to several touches.
To disable compression in some cases, another IPC message is sent.
The messages have exactly the same arguments, but by changing the message type,
compression is disabled for that message on IPC layer.
The patch tries to take rather conservative approach by disabling compression
in many cases. Compression is enabled only if the same touches are being changed,
or old touches and some new touch are changed (so the changed touches are a superset of the old touches).
The patch does not do anything with PointerEvent.getCoalescedEvents(). That implementation
would be quite a bit different and riskier for the next coming Fenix release.
Differential Revision: https://phabricator.services.mozilla.com/D63261
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
It's a testcase for Office Online Server duplicated from `test_bug1514940.html`.
The original test listens to `CheckKeyPressEventModel` event which is fired
when the `keypress` event model is changed from the default mode. Therefore,
this test also needs to listen to the event for avoiding intermittent failure
which is caused by running the tests before the mode change.
However, unfortunately, for keeping the performance of web apps which don't
need our mode changes, we can check the event only on debug build. Therefore,
this patch makes the test run only on debug build.
Finally, this patch renames `test_bug154940.html` too because it tests
special behavior on specific web app and the new test name explains it like
the test for Office Online Server.
Differential Revision: https://phabricator.services.mozilla.com/D64919
--HG--
rename : dom/events/test/test_bug1514940.html => dom/events/test/test_use_split_keypress_event_model_on_old_Confluence.html
extra : moz-landing-system : lando
So that we can get the correct client offset value and store other metrics
there and reuse them when the top browser window moves.
The client offset, browser window title bar and window decorated frame width,
is necessary to get element positions in OOP iframes in screen coordinates
for drag-and-drop etc.
This change also fixes event.screen{X,Y}. A mochitest in this commit fails
without this change with enabling fission at least on Linux. Note that in the
mochitest we have to use nsIDOMWindowUtils.synthesizeNativeMouseClick instead
of nsIDOMWindowUtils.sendMouseEvent since sendMouseEvent doesn't work in fission
world (bug 1528935).
Differential Revision: https://phabricator.services.mozilla.com/D62190
--HG--
extra : moz-landing-system : lando
This is being done to reduce the intermittent failures we see in this test.
There are other non-intermittent tests that measure the specific number of
pixels traveled by mousewheel events. The focus of this test seems to be
"Ensure that mousewheel scrolling and zooming are mutually exclusive" and
this change maintains that.
Depends on D62067
Differential Revision: https://phabricator.services.mozilla.com/D62130
--HG--
extra : moz-landing-system : lando
This change improves the intermittency of the test, but does not provably
eliminate it. The code comment in the relevant section gives the rationale.
Differential Revision: https://phabricator.services.mozilla.com/D61631
--HG--
extra : moz-landing-system : lando
This dummy test was added in bug 1000870 where all tests in the manifest had a
support-files attribute, then we hit bug 1150091. Currently, there are other
tests that get assigned DEFAULT, so we could just remove this dummy test.
Differential Revision: https://phabricator.services.mozilla.com/D61695
--HG--
extra : moz-landing-system : lando
Now that the zoom behavior involves more event round-trips, this test should
wait on the outcome of the input, instead of on the triggering event itself.
The way that SimpleTest.promiseWaitForCondition works, if the condition is
not reached quickly, instead of timing out, the test continues and the
following isnot check will fail.
Depends on D59260
Differential Revision: https://phabricator.services.mozilla.com/D61285
--HG--
extra : moz-landing-system : lando
All usage of `synthesizeDragStart()` is, starting drag, cancel `dragstart`,
and finally compares `dataTransfer` items and given expected data. So,
we can make the users use `synthesizePlainDragAndDrop()` instead. It's
better API because it computes position of mouse operations at runtime and
checks whether the drag start was succeeded with optional logging feature
(i.e., it's easier to debug of intermittent failures).
This patch creates `synthesizePlainDragAndCancel()` for convenience. It
handles `dragstart` instead of the callers.
Differential Revision: https://phabricator.services.mozilla.com/D58214
--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
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Edgar Chen
Razvan Maries
Kris Maglione
Emilio Cobos Álvarez
Dorel Luca
Coroiu Cristina
Gijs Kruitbosch
Brian Grinstead
Masayuki Nakano
Olli Pettay
Mark Banner
Hiroyuki Ikezoe
John Dai
Brad Werth
Ehsan Akhgari
Boris Zbarsky
Noemi Erli