When using Android 13 or later, there is no permission to enumerate
directories if on user storage. So `GetFilesHelper` and etc won't work on
Android.
We have to use content resolver APIs to enumerate files in directory.
So I have to add a method to collect files in FilePicker and return
DOM Files.
Differential Revision: https://phabricator.services.mozilla.com/D228761
As the input type can be changed to "submit" type during the click event, it may
end up triggering the form submission as the default action.
Differential Revision: https://phabricator.services.mozilla.com/D238781
Most of these elements are simple to support.
One slightly tricky item was <input type=date>, as testing indicates that the
front-end code usually (consistently?) hides the picker using setPickerState(),
which does not end up calling closeDateTimePicker() as might be expected.
So to properly track the open/closed state, I had to add a SetDateTimePickerState
webidl method, rather than just patching into the existing Open/Close calls.
Differential Revision: https://phabricator.services.mozilla.com/D234093
Most of these elements are simple to support.
One slightly tricky item was <input type=date>, as testing indicates that the
front-end code usually (consistently?) hides the picker using setPickerState(),
which does not end up calling closeDateTimePicker() as might be expected.
So to properly track the open/closed state, I had to add a SetDateTimePickerState
webidl method, rather than just patching into the existing Open/Close calls.
Differential Revision: https://phabricator.services.mozilla.com/D234093
This allows removing the special case for focus inside the datetime
widget (and fixes similar issues on video when you tab through
the video controls).
This is covered by test_input_datetime_focus_blur_events.html, but happy
to add a <video>-specific event if you think it'd be useful..
Differential Revision: https://phabricator.services.mozilla.com/D233180
This fixes failures in test_input_datetime_focus_blur_events.html and
such, but it seems like the shadow DOM retargetting should handle
this?
MANUAL PUSH: Orange fix CLOSED TREE
We want the blur handling to happen before the website has seen the
event, so that the value it sees is correct.
It also prevents the input to remain in the `:focus-visible` state
during blur.
Differential Revision: https://phabricator.services.mozilla.com/D233087
`screenX`, `screenY`, `clientX`, `clientY`, `x`, `y`, `offsetX` and `offsetY`
are now `double`. This patch makes the event classes aware of DOM events.
Currently, Chrome allows fractional values only for pointer events whose type
is not `click`, `auxclick` nor `contextmenu` (this exception is defined by the
Pointer Events spec). Therefore, this patch follows them.
I'm not sure about the untrusted events of non-pointer events, `click`,
`auxclick` and `contextmenu`. Chrome does check whether it's trusted or not
before applying `std::floor` or `std::round` at getter methods (I think that
using `std::round` in `offsetX` and `offsetY` is their bug at least for
untrusted events). This patch follows them for now but has a pref to allow
for all untrusted events.
Finally, for aligning to Chrome, this patch makes `click`, `auxclick` and
`contextmneu` keep using integer coordinates because it's recommended by the
Pointer Events spec.
Note that this changes the logic in `Event::GetPageCoords`. It rounded the
client point and scroll point before adding them. Similarly,
`Event::GetOffsetCoords` too. It rounded the client point before transforming
it. Therefore, in strictly speaking, this changes the behavior of other events
which keep returning integer coordinates. However, I don't see any issues in
our CI. So, for making the code simpler, let's use it and once we got some
regression reports caused by this, let's make them take additional param to
round the points to integer done in the traditional code.
Differential Revision: https://phabricator.services.mozilla.com/D222728
Returning uninitialized values is undefined behavior, and while the API
is such that the caller code wouldn't use the value in the case it's not
initialized, the C++ standard doesn't allow it and now clang 19 has a
change in an optimization pass that can end up miscompiling the code as
result.
Differential Revision: https://phabricator.services.mozilla.com/D228769
If the form submission originated from an event dispatch, this patch
ensures that the submitted image button coordinate is not the default.
Differential Revision: https://phabricator.services.mozilla.com/D224651
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
Now, we have `nsFocusManager::GetFocusedElementStatic()` which returns focused
element if the `nsFocusManager` instance is available. Therefore, if
`nsFocusManager::GetFocusedElement()` users do not use other methods of
`nsFocusManager`, they can use `nsFocusManager::GetFocusedElementStatic()` and
make themselves simpler.
Note that some callers return early if `nsFocusManager` is not available, but
they do not return error and `nsFocusManager` instance is available in most
time of the life time of the process. Therefore, we can simply stop using the
early return.
Differential Revision: https://phabricator.services.mozilla.com/D217527
It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
It turns out that many sites are modifying the field state immediately after a value has been autofilled, typically to format the value such as add spaces between parts of a credit card number
Differential Revision: https://phabricator.services.mozilla.com/D215113
The C++ code change here is simply replacing an ifdef with a pref-check (and
associated reindentation for being placed in an "if"-block).
The pref is off-by-default for now, since no other browser seems to modify
these fields through mousewheel scrolling, and users seem to be surprised when
they encounter the behavior in Firefox. See discussion on the bugzilla page.
Note: now that this behavior is controlled by a pref, we don't need to have
platform-specific #ifdefs and "skip-if" test exemptions. If we decide to bring
this behavior back on certain platforms, we can do so by simply changing the
default value of the pref on those platforms.
Differential Revision: https://phabricator.services.mozilla.com/D175719
This is needed because we want implicit width of number and text
controls be the same, but explicit width be different to account for the
spinners. See:
data:text/html,<input type="number"><br><input type="text"><br><input type="number" min="1" max="9"><br><input type="text" size="1">
For example. This patch on its own shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215549
Split out from the other patch for readability. This doesn't change
behavior but unifies where we store the buttons of
number/search/password inputs.
Differential Revision: https://phabricator.services.mozilla.com/D215548
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
