I was confused by the old flag `this._ignoreMouseEvents`. It's now set to
`true` by `startAutoscroll`, but `stopScroll` does not set it to `false`.
Instead, `this._scrollable` is available for this purpose.
Then, the test does not pass only on 32bit Windows and macOS. The failure is,
when clicking on left mouse button, `click` event is fired in the content.
The difference from the other platforms, the click is handled by APZ on them.
Therefore, there is no chance to consume click event in `AutoScrollParent`,
`AutoScrollChild` nor `browser-custom-element`.
Differential Revision: https://phabricator.services.mozilla.com/D107324
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
The test previously depended on the position of the blocked request
in the request list view, This causes the test to fail intermittently
when the list is out of order.
This fix instead finds the request using the name in the url which is
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D109497
When we are guarding that no argument is forwarded, ArgumentsReplacer::visitGuardArgumentsObjectFlags asserts that no formal argument is aliased. This is too general: in strict mode, arguments can be aliased by the call object, but not forwarded.
This patch fixes the check in `anyFormalIsAliased` and renames it for clarity.
(I tried adding assertions in `MaybeForwardToCallObject` that we only mark arguments as forwarded if `script->anyFormalIsAliased()`, but that runs into problems with `arguments.callee.arguments` and `ArgumentsObject::createUnexpected`.)
Differential Revision: https://phabricator.services.mozilla.com/D109413
* We make some changes to heuristicsRegexp.js to improve accuracy. (Nothing else uses these regexps, so they're safe to change.) The commenting out of some languages in the expiration fields are because they caused a lot of false positives, according to Daniel Hertenstein's recollection. In any case, we've never preffed CC autofill on for those languages.
* Delete a few tests from test_known_strings.js and one from test_getInfo.js, which were testing for the presence of regexes we removed.
* Delete tests of CC autofill against third-party sites. These tests no longer work as xpcshell tests, since Fathom expects full layout and style information. The spirit of these tests is maintained by adding these pages to Fathom's training, validation, and testing corpora at 2bfcdf23dc. A few don't make it due to iframes which confound Fathom's capture tools, but the rest all succeed--and now improve the ML model as well as acting as tests. The training results after said integration reflect this improvement, which boosts testing precision and recall for every type.
* Add a mochitest to ensure the Fathom integration code can surface a decision that a field should not be autofilled. Decisions that go the other way are taken care of by the existing autofill tests.
Differential Revision: https://phabricator.services.mozilla.com/D100141
Get a version which will throw a specific error when isVisible() is run on elements that aren't in a window.
Some of the xpcshell tests crash because they transit through the codepath that calls Fathom, even though they don't do anything with its output. Fathom gets cranky and throws an exception because the elements it's evaluating don't live within a window object (an artifact of the test harness). This lets us swallow that exception and no others.
Differential Revision: https://phabricator.services.mozilla.com/D107906
We need it from both FormAutofillHeuristics and CreditCardRuleset, and it would make a circular import otherwise: FormAutofillHeuristics -> CreditCardRuleset -> FormAutofillHeuristics.
Differential Revision: https://phabricator.services.mozilla.com/D100140
Implement an observer to wait for correct window events in order to restore tab
content. Non-SHIP code restores about:reader scroll position after receiving
"AboutReaderContentReady" event, so to achieve the same thing with session
history in parent enabled, we can wait for "AboutReader:Ready" event.
Differential Revision: https://phabricator.services.mozilla.com/D108712
Masayuki Nakano
Sebastian Hengst
Hubert Boma Manilla
Emma Malysz
Aaron Klotz
Andrew Halberstadt
Butkovits Atila
Iain Ireland
Erik Rose
Barret Rennie
Tom Ritter
Miko Mynttinen
Emilio Cobos Álvarez
Anny Gakhokidze
Kashav Madan
Marco Bonardo
Sam Foster
Masatoshi Kimura
Anshul Sahai
alwu
Noemi Erli
Asumu Takikawa