Bug 730114 - Subscriptions no longer readable by accessibility api
Subscriptions no longer readable by accessibility api
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Michael Stead
J.C. Molet
Depends On:
Blocks: rhsm-rhel62
  Show dependency treegraph
Reported: 2011-08-11 15:40 EDT by J.C. Molet
Modified: 2011-12-06 12:23 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-12-06 12:23:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
blank row names (156.50 KB, image/png)
2011-08-11 15:40 EDT, J.C. Molet
no flags Details

  None (edit)
Description J.C. Molet 2011-08-11 15:40:45 EDT
Created attachment 517880 [details]
blank row names

Description of problem:
The rows in the subscriptions column of the "All Available Subscriptions" tab do not have any accessibility name. This also applies to the subscriptions in the Subscription Assistant. This means accessibility readers can't tell what is there and this blocks automation of anything involving subscribing or unsubscribing.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open subscription manager gui
2. Register
3. Try read any cell in column 0 in the "All Subscriptons View" in the "all available subscriptions" tab or the "Subscriptions List" in the subscription assistant.  (see my screenshot using sniff)
Actual results:
The cells have no accessibility name and cannot be read.

Expected results:
The cell would be named the same thing as the subscription name.  In the screenshot, for example, the highlighted cell in the AT-SPI Browser would be named the same thing as It's 3rd child:  "Awesome OS Serrver Basic".  Alternatively the other information the cells could be moved to its own column.

Additional info:
Comment 1 Michael Stead 2011-08-24 13:21:35 EDT
This was fixed a while ago. I forgot to close the issue. :(

Fix committed in master branch - 7cbb9d15dd7d41722479781b72ade7c31fe67481
Comment 3 J.C. Molet 2011-08-30 13:18:37 EDT
verified.  The extra info was moved to their own unique column.

Comment 4 errata-xmlrpc 2011-12-06 12:23:26 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.