GNOME Bugzilla – Bug 543496
Problems with performing mouse clicks in Firefox
Last modified: 2009-03-10 00:05:12 UTC
Christian from the orca-list reported that using Orca to click on items in Firefox isn't working: > Here is an example. > I wanted to do the Internet security test from the following > address: > https://www.grc.com/x/ne.dll?bh0bkyd2 > Press the proceed button. > On the next page you'll find buttons for the different tests you > can do. You need to click on them for some reason. Pressing space > on them don't work. I have the same problem in Windows. But if I > route the mouse to the button and click on it it will work. I can confirm this. Visually I see that we are routing the mouse pointer to the item, but placing it just to the left of the text displayed for that item. If you click there (even without Orca, i.e. physically using the mouse to click), nothing happens. You have to click on the text in order for it to work.
Created attachment 114738 [details] [review] revision 1 This is the "proof of concept" version. I dunno if this is the right thing to do or not, but it seems to solve the problem and if nothing else, it's a starting point for discussing a solution. What this patch does is get the current accessible and see if there are any clicky (clicklike? clickful?) actions associated with it. For now, I defined clicky as "click" and "press". If the current accessible has either of actions, we look at the word and click dead center. Otherwise, we do what we currently do, namely look at the character and click just to the left. I've tried this with various and sundry controls in the Orca preferences dialog, in Firefox, and in Gedit (in the latter two cases, including while flat reviewing text). When I pylint it, I get the following error: E1103:1563:Context.clickCurrent: Instance of 'list' has no 'queryAction' member (but some types could not be inferred) I'm not queryAction'ing on a list, and the queryAction is wrapped in a try/except. <shrugs> Will, whatcha think? Also, given that this solution (whatever it winds up being) make pages with these sorts of buttons more accessible, I think this should be targetted for 2.24.
(In reply to comment #1) > Created an attachment (id=114738) [edit] > revision 1 > > This is the "proof of concept" version. I dunno if this is the right thing to > do or not, but it seems to solve the problem and if nothing else, it's a > starting point for discussing a solution. It seems nice and creative to me. I'd be OK with checking it in. > When I pylint it, I get the following error: > > E1103:1563:Context.clickCurrent: Instance of 'list' has no 'queryAction' member > (but some types could not be inferred) Yeah - just disable E1103 locally. Look in default.py for "E1103" for an example.
Created attachment 114741 [details] [review] revision 2: added the line to disable E1103 locally > It seems nice and creative to me. I'd be OK with checking it in. Meaning "go for it" or meaning "testing required"? :-) > Yeah - just disable E1103 locally. Look in default.py for "E1103" for an > example. Done. Pylints to a 10 now. Thanks! Also ran the one regression test we seem to have which left-clicks (gtk-demo/role_text_multiline_navigation.py), and the patch passed the test. (Writing more tests should probably be on our to-do list.) One question: I intentionally did not add the "jump" action to the clicky action group. The "jump" action is associated with links. Here's the result: If you flat review to a textual link and are at the beginning of that link (be it by character, word, or line), clicking will move you to the link but not actually click on it. If you're anywhere else in the link, clicking on it will click on the link which will cause it to be activated. My thinking was this: 1. You can press Enter on a link so you don't need to actually need to be able to physically click on it. 2. It might be nice to be able to route the caret to your current position (i.e. just before the link) without activating the link. On the flip side, one could argue that if you click on a link it should activate the link. Period. Thoughts?
(In reply to comment #3) > Created an attachment (id=114741) [edit] > revision 2: added the line to disable E1103 locally > > > It seems nice and creative to me. I'd be OK with checking it in. > > Meaning "go for it" or meaning "testing required"? :-) I meant check it in, but since you raise the following, I take it back until the UI design decision is made. :-) > One question: I intentionally did not add the "jump" action to the clicky > action group. ... So, let's wait to see what Mike and the users decide.
Created attachment 114928 [details] [review] revision 3: the KISS principle Will and I took a closer look at this. It turns out to be a much simpler problem/solution. In the code we have the following comment: # We try to click to the left of center. This is to # handle toolkits that will offset the caret position to # the right if you click dead on center of a character. # And then we fail to do that. :-) We click at point x (i.e. the left edge) rather than just to the left of center (x - (width/2) - 1). When we do what the comment says, the issue reported in this bug goes away. Thanks Will! (already pylinted and confirmed to work both for objects and for text)
Since we're not doing the "clicky" thing after all, removing Mike's name.
Will and I discussed this. Because it is a simple fix, and because the change causes us to do what we thought we were doing (and should be doing) in the first place, I've gone ahead and committed this to trunk. Moving to pending.
As far as I can tell this seems to work.
Thanks Mike. I've tested it quite a bit as well so I think it's good. Closing as FIXED.