GitLab

Normally when a user copies and pastes a file/folder in a file manager,
we get a selection-changed event from the container of the just-pasted
item and want to update our location. But when copying and pasting a
large number of items in Caja, we are placed in a new window for the
progress and eventually get the aforementioned selection-changed event.
Therefore, be sure the container is in the active window before updating
our location.

It's extremely rare that a filler would have 0 children. If it claims
to have 0, that suggests the app/toolkit is failing to emit children-
changed:add events. Clearing the cache can sometimes work around this
problem, but it is not 100% reliable and can require multiple attempts.

When we search for the first valid caret position at/after a specified
offset, we typically descend the element if the character at offset is
an embedded object character. In the case of offscreen text which is
exposed to us as one character per line, this can lead to getting stuck
or looping because we always return a range of 0:length for the broken
element.

It turns out that we sometimes get non-broken text when the off-screen
text at offset happens to be a space, but for all other offsets we
get just a single-character per line. Therefore also ignore spaces
when doing the sanity check. Ditto for the replacement character. We
can see the latter in some implementations when we use getText() for
a length of one at the offset of a multibyte character. In theory,
we should instead call getTextAtOffset() asking for a character. But
due to other bugs in (at least) Gecko, that is even less reliable.

(cherry picked from commit 45ca81d2)

Authors are using ARIA to mark things up as GUI components (menus,
toolbars, etc.). But then they are not providing any associated
navigation. As a result, the user has to know to switch to native
browser navigation (e.g. Tab) to access the descendant items.
Users who don't realize this can wind up skipping over items.
Therefore make the following roles always descendable in browse
mode:

* Menu
* Menu Bar
* Tool Bar
* Tree
* Tree Table

When authors hide text just for screen-reader users to find, it is
often exposed to us via the accessible text interface as if there were
only one character per line. We have logic to check for this case, but
it wasn't catching things like:

* our getting a valid line when the first character is an embedded
  object, but subsequent characters are not
* our getting a character along with a space (two characters are
  not a single character)

Therefore add handling to ignore results when the character at offset
is embedded object, and strip whitespace before examining the supposed
line at offset.

At least some users have Tab input events for which there is a modifier
we don't recognize. As a result, we can fail to recognize Tab/Shift+Tab
navigation which can impact what we do or do not present. Therefore,
just filter out things we don't wish to treat as Tab navigation, such
as Alt, Ctrl, and the Orca modifier.

For some browsers (currently just Gecko-based ones), we sanity-check
all results we get from the AtkText implementations because there are
many bogus results. Sometimes, however, we get zero-length text at
offset results which are valid. This happens in plain-text documents.
Turns out it can also happen in preformatted-text elements. In these
instances, other AtkText bugs (e.g. bogus text-range extents) can
prevent our hack around from obtaining the right text range for the
specified offset and we wind up treating all the text as if it were
on a single line. Treating preformatted-text elements as plain text
causes us to not attempt broken text recovery when we shouldn't.

Given a plain text file viewed in a browser or browser-based email
application, we were collapsing a series of newlines into a single
newline in browse mode. This results in a different presentation
than one gets in plain text editors such as Gedit, so stop doing
this.

This setting controls whether or not Orca says "blank" when arrowing
to an empty line (not whether or not blank lines are skipped in browse
mode). We weren't respecting this setting in the Web speech generator,
and speaking "blank" for each empty line.

The presence of multiple newline characters in content can lead to us
getting the same line via the accessible text interface. If we don't
sanity check and handle this condition, the user can get stuck in
content. We were handling this condition for moving forward by line,
but not backward by line. Apply the same strategy, namely if we get
the same line for a previous offset decrement the offset again and
try once more.

We were resetting the locusOfFocus in response to caret-moved events
received with each selection change. These events should be ignored
when arrowing up/down in the popup for a single-line autocomplete.

This change is being made in the web script rather than the Chromium-
specific support because this condition could happen in Firefox too.

Chromium has accessible menu items which are not focusable and therefore
do not have a posinset and setsize calculated. But they may claim to be
the selected item when an accessible child is selected (e.g. "zoom" when
"+" or "-" gains focus. Normally we calculate posinset and setsize when
the application hasn't provided it. We don't want to do that in the case
of menu items like "zoom" because our result will not jibe with the
values of its siblings. Thus if a sibling has a value, assume that the
missing attributes are missing on purpose.

* Fix bug causing them to be skipped over in SayAll because they
  are labelling content.
* Don't repeat the name of the figure when the first thing being
  presented is the caption from which the figure's name derives.

Fixes #190.

Once one arrows past zoom-related or edit-related items in the three-dot
menu, zoom and edit each claim to be selected. Because AtkSelection does
not report the selected children for this menu, we resort to examining
all children to find those with state-selected and wind up with two:
the real selected child and zoom or edit. All this needs to be fixed in
Chromium, but it appears that catching this condition and sanity-checking
items by also examining the focused state is a safe workaround in the
meantime.

Chrome/Chromium appears to be emitting a caret-moved event before the
focus event the first time a new input/entry gains focus as a result
of tabbing into it. When this occurs, we update the locusOfFocus but
wind up presenting nothing because tabbing into editable text is not
a case handled by the default script.

In this particular case, we know that we will be getting a focus
event from the browser (and if we don't, we need that fixed in the
browser). So it's safe to ignore this initial caret-moved event and
wait for the focus event to do the presentation.

Trying to shave time off for shutdown.

We cannot guarantee that there will be an associated text-changed:insert
event for a text-changed:delete event, though we usually see that from
VTE.