Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
This revision changes the logic in MathMLMarkupMap such that mtd elements create
generic ARIA grid accessibles if the display style for the element is something
other than 'table'. This revision also adds a test that verifies that the roles
remain as expected, even with this change.
Differential Revision: https://phabricator.services.mozilla.com/D163898
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
In bug 1766794, I replaced partial invalidation of cached offsets with full cache invalidation.
I did this to simplify the code, since the offsets cache was being extended to RemoteAccessible.
This is fine for RemoteAccessible because offsets are only needed there when clients query them.
However, for local HyperTextAccessible, offsets are always required to fire text events.
Full cache invalidation there meant that many insertions into a large container was very expensive.
To fix this, reinstate the ability to partially invalidate the offsets cache.
This is largely the code I previously removed from HyperTextAccessible, with some tweaks for readability.
Differential Revision: https://phabricator.services.mozilla.com/D163418
We will soon have an offsets array in the parent process cache which is not built in one shot.
Instead, we will gradually cache more offsets as they are requested.
To do this, we need a way to get an array from the cache which can be modified in-place.
Differential Revision: https://phabricator.services.mozilla.com/D163417
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
This revision addresses an issue with th elements within tables that don't have
the table CSS display style. In these cases, where we create an
ARIAGridCellAccessible for a th, we fail to report rowheader and columnheader
properly, since ARIAGridCellAccessible doesn't know how to handle th elements.
This revision fixes the problem by moving the th NativeRole logic into the
TableCellAccessible class, then calling that logic from both the ARIA grid cell
accessible NativeRole and from HTMLTableHeaderCellAccessible, as before. This
revision also updates tests reliant on the old behavior, including beefing up
an existing test aimed at this bug specifically.
Differential Revision: https://phabricator.services.mozilla.com/D163371
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
The pivot should never cross from remote into parent process local
containers. We need to explicitly set the root for the pivot, and
assert for this in the pivot traversal methods.
Differential Revision: https://phabricator.services.mozilla.com/D163285
This can happen if we're pushing the tree for only moved (no new) Accessibles, since we don't send cache pushes for those.
It can also happen if an Accessible generates no cache data, which is rare but probably not impossible.
Making IPDL calls with no data is wasteful, so don't do it.
Differential Revision: https://phabricator.services.mozilla.com/D163203
Trying to access a local OuterDocAccessible from the Android UI thread was causing a crash.
We shouldn't be crossing document boundaries anyway.
Differential Revision: https://phabricator.services.mozilla.com/D163067
After bug 1779156, show events were fired from RecvCache, rather than from RecvShowEvent.
This was done to ensure that cache data was available when the event was fired.
However, because RecvCache fired a show event for every initial cache push, this meant that it also fired one for the document itself, plus all the document's initial direct children.
Firing an event for the document caused problems for ATK, since the parent was null for all top level documents.
This also meant we were firing a lot of unnecessary show events, which could be a performance problem for documents with a lot of initial direct children.
To fix this, provide an explicit argument to PDocAccessible::Cache specifying whether to dispatch a show event or not.
This replaces the existing aFinal argument, which was never used.
Differential Revision: https://phabricator.services.mozilla.com/D163192
This never really belonged in XULMenuItemAccessibleWrap::Name, as it's specific to MSAA.
This will allow us to remove this Wrap class.
Differential Revision: https://phabricator.services.mozilla.com/D162455
When a selection event is dropped due to coalescence, we still include the impacted Accessible in the SelectedAccessiblesChanged notification we send to the parent process.
Although we skip events with defunct targets, we weren't skipping defunct items referenced by selection events.
This meant that if an Accessible was selected/unselected but was shut down before we sent SelectedAccessiblesChanged, the notification would include a dead Accessible.
This was causing an assertion in the parent process.
To fix this, we now ignore defunct items in selection events.
Differential Revision: https://phabricator.services.mozilla.com/D162551
Gecko switched to mutating the tree structure for aria-owns many years ago instead of using relations, so this is now dead code.
Note that a test case was added for this aria-owns case in accessible/tests/mochitest/role/test_general.html in bug 1044431.
This still passes with this code removed.
Differential Revision: https://phabricator.services.mozilla.com/D162459
PruneOrInsertSubtree already has code to deal with this.
However, layout previously didn't notify a11y about the change if a shadow root was attached without any content, so PruneOrInsertSubtree was never called.
We now schedule re-evaluation of the a11y tree of the shadow host when DOM notifies layout about the attached shadow root.
This will call PruneOrInsertSubtree during the next refresh tick.
Differential Revision: https://phabricator.services.mozilla.com/D162263
When we push a cache update for tables, we call IsProbablyLayoutTable.
That in turn checks whether the first grandchild LocalAccessible of each row is an abbreviation.
If there is a malformed table containing an iframe as a child of a row, this grandchild will be an embedded DocAccessible.
Since a DocAccessible has a null mContent prior to DoInitialUpdate, calling IsAbbreviation on this would previously crash because it didn't null check mContent.
The fix is simply to null check mContent.
Differential Revision: https://phabricator.services.mozilla.com/D162360
This reduces memory used by the cache, since the same font family and language strings often occur many times in the same document (and likely even across documents).
Differential Revision: https://phabricator.services.mozilla.com/D162276
Layout doesn't consider these types of th elements to be table cells since there
is no underlying table layout. This patch asks layout whether it considers the
frame's accessible type to be a table cell accessible. If it does, continue to
use the HTMLTableHeaderCellAccessible, but - otherwise - use a generic grid cell
accessible. This revision also adds a test to verify the behavior of th in this
situation. This essentially repeats the logic already in existence for td.
Differential Revision: https://phabricator.services.mozilla.com/D162357
This doesn't change behavior, but clarifies a bit the naming to match
the scrollIntoView() API. Also makes the name generic (rather than
Top/Left/etc), since for scrollIntoView we want to make the axes be
logical.
That will be done in bug 1789464 (probably via an extra ScrollFlag).
Differential Revision: https://phabricator.services.mozilla.com/D162286
The code which calculated the focused state in RemoteAccessibleBase was incorrect.
It used the focused BrowserParent rather than the focused BrowsingContext to determine if the document was focused, which meant it treated a top level document as focused even when an embedded in-process iframe had focus.
FocusManager::FocusedAccessible (and now FocusManager::IsFocused) do the right thing, so we can use IsFocused instead.
LocalAccessible already used IsFocused to calculate the focused state.
Since both local and remote both now do the same thing, we can move this into Accessible::ApplyImplicitState.
Differential Revision: https://phabricator.services.mozilla.com/D161876
Previously, IsFocused had a separate implementation instead of just using FocusedAccessible because of cases years ago where it would unintentionally cause us to create a DocAccessible for an initial about:blank document.
As far as I can tell, we no longer prevent creation of DocAccessibles for initial documents because they aren't necessarily temporary documents.
Therefore, we can just compare against FocusedAccessible now.
Since FocusedAccessible is already unified, this makes unifying IsFocused very simple.
This paves the way for unifying correct calculation of the focused state.
This necessitated a change to FocusedLocalAccessible to prevent it from trying to get/create a DocAccessible when the accessibility service is shutting down.
Shutting down the service shuts down all documents, and shutting down a document now calls IsFocused, which causes us to get/create a DocAccessible.
That isn't safe while the service is shutting down and was causing a crash.
Differential Revision: https://phabricator.services.mozilla.com/D161875
IN subsequent patches, IsFocused will be called when querying the state of a RemoteAccessible and IsFocused calls FocusedAccessible.
A RemoteAccessible can be queried from the Android UI thread (which is different to Gecko's main thread), but it's not safe to deal with LocalAccessibles off the main thread.
Therefore, don't try to call FocusedLocalAccessible in this case.
Differential Revision: https://phabricator.services.mozilla.com/D162177
See the code comment for further details.
In subsequent patches, IsFocused is refactored to call FocusedAccessible, which asserts that mActiveItem is not defunct.
Without this active item fix, that change would cause accessible/tests/mochitest/actions/test_keys.xhtml to assert.
Differential Revision: https://phabricator.services.mozilla.com/D161887
This revision expands the reporting of ARIA combobox values to non-editable
comboboxes with no selected option. In these cases, according to the spec, we
should report a value "represented by its descendant elements [...] determined
using the same method used to compute the name of a button from its descendant
content." In this revision, I interpret that to mean, roughly, nsTextEquivUtils'
GetTextEquivFromSubtree, which is tantamount to the name calculation, except
that it crucially avoids rejecting the combobox for having eNameFromValueRule,
unlike GetNameFromSubtree. This revision updates this logic in LocalAccessible
and RemoteAccessibleBase, and adds tests to verify the above.
Differential Revision: https://phabricator.services.mozilla.com/D162229
The code which calculated the focused state in RemoteAccessibleBase was incorrect.
It used the focused BrowserParent rather than the focused BrowsingContext to determine if the document was focused, which meant it treated a top level document as focused even when an embedded in-process iframe had focus.
FocusManager::FocusedAccessible (and now FocusManager::IsFocused) do the right thing, so we can use IsFocused instead.
LocalAccessible already used IsFocused to calculate the focused state.
Since both local and remote both now do the same thing, we can move this into Accessible::ApplyImplicitState.
Differential Revision: https://phabricator.services.mozilla.com/D161876
Previously, IsFocused had a separate implementation instead of just using FocusedAccessible because of cases years ago where it would unintentionally cause us to create a DocAccessible for an initial about:blank document.
As far as I can tell, we no longer prevent creation of DocAccessibles for initial documents because they aren't necessarily temporary documents.
Therefore, we can just compare against FocusedAccessible now.
Since FocusedAccessible is already unified, this makes unifying IsFocused very simple.
This paves the way for unifying correct calculation of the focused state.
Differential Revision: https://phabricator.services.mozilla.com/D161875
