After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 135314 - gok can't see mozilla menus/toolbars/ui
gok can't see mozilla menus/toolbars/ui
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other All
: High major
: ---
Assigned To: bill.haneman
bill.haneman
Depends on:
Blocks:
 
 
Reported: 2004-02-24 20:03 UTC by bill.haneman
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to search more exhaustively inside toolbars (1.67 KB, patch)
2004-03-13 11:49 UTC, bill.haneman
none Details | Review

Description bill.haneman 2004-02-24 20:03:18 UTC
at-poke can see mozilla components, but gok doesn't find them.  Not sure
why yet.
Comment 1 bill.haneman 2004-02-25 17:59:07 UTC
There are several problems here, apparent from an examination with
at-poke:

(1) mozilla's menu hierarchy differs from other apps in that menus are
children of toolbar-role objects, etc.
(2) the menus themselves seem to have a broken/incomplete hierarchy;
(3) the action names of the menu items are broken;
(4) the actions themselves are not invokable (i.e. do nothing when
invoked)

2 through 4 are mozilla bugs, #1 implies that gok needs a little
revision to its search algorithm so that we find the menus.

Comment 2 korn 2004-02-25 19:54:22 UTC
Have these been filed as mozilla accessibility bugs?
Comment 3 bill.haneman 2004-02-25 20:00:26 UTC
Not yet.  You are welcome to do so if you like.
Comment 4 David Bolter 2004-02-25 20:38:32 UTC
Bill are you taking this one?  I could have a look at fixing part 1...
Comment 5 bill.haneman 2004-02-25 20:46:48 UTC
If you like; I'd prefer to glance at the patch first though, since I
may  not have documented the search implementation very well and so
the right thing to do might not be apparent.

The main oddity with mozilla's hierarchy (aside from obviously broken
stuff) is that the menubar is a child of a toolbar.  I believe that at
present we may assume that toolbars contain toolbar-items (silly me ;-)

thanks
Comment 6 David Bolter 2004-02-25 20:58:40 UTC
I'm guessing it is gok_spy_is_menu_role that needs to include another
catch case...  i.e. toolbar   ... because obviously toolbars can have
menus ;-)

I can't readily test this potential fix with mozilla so maybe I'll
throw it back to you...  can you try adding a
		(role ==  SPI_ROLE_TOOLBAR) ||

...and see if it fixes it?
Comment 7 bill.haneman 2004-02-25 21:59:13 UTC
the fix would have to be a little more complex than the above, since
the toolbar would not (itself) be a "menu role object" - one thing we
need to do is ensure that we are checking inside toolbar containers
when seeking menus.  But I'll be happy to investigate this one further.
Comment 8 bill.haneman 2004-02-26 12:02:36 UTC
I don't think we should attempt a fix for "#1" above until the mozilla
issues are solved - because we would (if we exposed the menu items)
only be exposing non-functional items to the user (because the mozilla
ATK menu items themselves are incomplete, and non-functional).
Comment 10 bill.haneman 2004-03-13 11:46:18 UTC
inaddition to the mozilla fixes above (and some other mozilla bugs
regarding the use of AtkStateSet and ATK_STATE_SHOWING), the following
patch to GOK logic is required; GOK doesn't currently expect to find
menus and editboxes inside toolbars (where mozilla puts them).  Patch
fixes that and so far appears not to have significant side-effects
(thoug some additional testing is warranted).
Comment 11 bill.haneman 2004-03-13 11:49:45 UTC
Created attachment 25588 [details] [review]
patch to search more exhaustively inside toolbars
Comment 12 bill.haneman 2004-03-24 11:08:42 UTC
fixed in cvs.