For GUI list items, we need to be able to handle interactive descendants.
But the Thunderbird message list items have named sections as descendants
causing us to be chatty. Therefore add roles that are common to web content
but not GUI list items to those we ignore when generating descendants.

We don't need the geometry to use CapsLock as the Orca modifier
and people complain about seeing this error in Wayland.

ac3239d4 removed special casing of links from _generate_accessible_name.
That special casing had been in place to make link presentation less chatty,
but it caused presentation of links in the side bar of GMail to break. While
ac3239d4 fixed links in GMail's side bar, it reintroduced chattiness in
other places, such as when a link was split into multiple objects due to
having a child object.

This commit restores the special-casing, but instead of checking if the
link has presentable text, it instead checks to see if we've already
figured out the substring we want to present. If we've already figured
out the substring, use it rather than the name. This solution appears
to work in both scenarios.

Only filter out descendant labels based on name if the container
has a name. If both the label and the container lack a name,
checking if the former is `in` the latter will return True.

Otherwise we're in danger of presenting the full list item's text
and then repeating part of it when one down arrows in a multi-line
list item.

The value only makes sense if it's focused. If it's an ancestor
the split pane is typically just a container whose inclusion is
just chattiness.

Whether a page tab is sensitive, expanded, has a mnemonic, its
position in set, etc., is relevant when it has focus or it becomes
newly selected. In the context of ancestry, its too chatty. Therefore
limit the ancestor presentation to name and role.

It should instead be included in the roles which are likely
to have static text we should present. The fact that it is
already being included in such roles is why it was being
double-presented.

Otherwise we will double-present the description if the user has
description presentation enabled.

_generate_accessible_label_and_name() attempts to eliminate chattiness
with labels, ancestors, etc. By filtering the name if the object isn't
the focused object and the name of object is either the name of the
focused object or the description of the focused object. This does
not catch the following scenario: The focused object has a name,
an ancestor object lacks a name BUT has a description which is the
same as the name of the focused object. When generating the name of
the ancestor, we'll fall back on the description thus presenting it
twice.

Add a similar fallback in _generate_accessible_label_and_name(),
so if the name/description is the name or description of the focused
object, filter it out.

This had been set aside due to the table-cell formatting-string mess.
Formatting strings are gone, making this (now) a simple change.

See issue #298.

_generate_accessible_description was not handling the following
scenario: object is an ancestor of the current focus and the
description of the object is the name or description of the current
focus. When that occurs, we'll present the description for the
ancestor and then as the name or description of the newly-focused
object. Add a check for this condition to eliminate the double
presentation.

This fallback was being done silently by the now-removed
displayedText().

Now that we support aria-disabled on grid cells, some users have
reported Orca saying "grayed" for table cells. That means that in
some versions of Calc, the cells lack the sensitive state. Work
around that by not generating the sensitive state for spreadsheet
cells.

Newly-added mate-terminal page tabs sometimes lack the "showing" state.
As a result, if the user creates a new terminal, adds some text, and
attempts flat review, we'll ignore the terminal content because the
ancestor page tab claims to not be showing.

Try clearing the cache to see if the problem is just a missing state
change event.

default.process_routing_key() calls braille.process_routing_key().
The latter, upon finding a flash message, restores the pre-message
contents and returns early. But if it doesn't find a flash message,
it routes the cursor to the specified location, possibly triggering
a click action. As a result, when default.process_routing_key()
kills the flash message first, the user thinks they're clearing the
flash message, but they may instead be clicking on something. Fix
this by interrupting presentation with killFlash set to False.

The web script's presentObject presents the entire object, and all of
its contents. When using the object navigator, this is not desired.

Because removing workarounds is regressing the end user experience,
add the following hack: When we receive an active descendant event
from LO, and the event source is not an ancestor of the current focus:

1. Silently set the locus of focus to the parent of the event source.
   Otherwise we'll be super chatty in response to the next item.
2. Non-silently set the locus of focus to the event source. This will
   cause us to present the sheet name.
3. Allow the default script to do its thing which will set the locus
   of focus to the cell with the common ancestor being the table and
   thus it will not be double-spoken.

Update to upstream version '47.0'
with Debian dir c914f15da9aece354d41af708d404cc173b71723

orca Debian release 47.0-1