Increase the Mouse Routing Efficiency In Browse Mode #2029

Closed
nvaccessAuto opened this Issue Jan 5, 2012 · 8 comments

1 participant

@nvaccessAuto

Reported by parham on 2012-01-05 07:56
When in browse mode and trying to activate the hover event of an item, pressing insert+numpadDivide (or insert+shift+f9 in case of the laptop layout) does not always route the mouse pointer exactly to that element. This is not always reproducible even on the same page, but sometimes the algorithm doesn't work (E.G. I am in the WordPress dashboard and I choose the list number five in the dashboard menu, but the mouse gets routed to item 3).

@nvaccessAuto

Comment 1 by jteh on 2012-01-05 08:11
It currently routes to the top left corner of the underlying object. However, this may be problematic if the object has borders. It'd probably make sense to change this to the centre of the object, which is consistent with this command's normal behaviour when text cannot be mapped to points.
Changes:
Milestone changed from None to 2012.1

@nvaccessAuto

Comment 2 by jteh on 2012-01-05 23:29
comment:1 implemented in 60d4718, which should hopefully fix your particular issue.
Changes:
State: closed

@nvaccessAuto

Comment 3 by parham on 2012-03-07 08:37
This issue has come back, perhaps now in another form.

On a page which NVDA worked fine with previously, I cannot route the mouse as I could before (I.E. the hover event doesn't get triggered). Here's the debug warning log. I hope it helps:

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (12:00:02):
Developer info for navigator object:
name: u'CheetahWorks -'
role: ROLE_DOCUMENT
states: STATE_READONLY, STATE_FOCUSABLE
Python object: <NVDAObjects.Dynamic_DocumentBrokenFocusedStateMozillaIAccessible object at 0x05790590>
Python class mro: (<class 'NVDAObjects.Dynamic_DocumentBrokenFocusedStateMozillaIAccessible'>, <class 'NVDAObjects.IAccessible.mozilla.Document'>, <class 'NVDAObjects.IAccessible.mozilla.BrokenFocusedState'>, <class 'NVDAObjects.IAccessible.mozilla.Mozilla'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u''
location: (0, 45, 1280, 921)
value: None
appModule: <'firefox' (appName u'firefox', process ID 4564) at address 576d8b0>
TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'>
windowHandle: 2296024L
windowClassName: u'MozillaWindowClass'
windowControlID: 0
windowStyle: 399441920
windowThreadID: 228
windowText: u'CheetahWorks - - Mozilla Firefox'
IAccessibleObject: <POINTER(IAccessible2) ptr=0x376584 at 5754a80>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2296024, objectID=-4, childID=-190169520
IAccessible accRole: ROLE_SYSTEM_DOCUMENT
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048640)
@nvaccessAuto

Comment 4 by jteh on 2012-03-07 08:39
Sorry. This doesn't help. We need a URL and steps to reproduce if possible.

@nvaccessAuto

Comment 5 by jteh on 2012-03-07 08:40
Btw, are you saying the fix in 60d4718 introduced this problem? Are you certain of this? Please test with NVDA 2011.3 if not. Thanks.

@nvaccessAuto

Comment 6 by parham (in reply to comment 5) on 2012-03-13 14:00
Replying to jteh:

Btw, are you saying the fix in 60d4718 introduced this problem? Are you certain of this? Please test with NVDA 2011.3 if not. Thanks.

No, this changeset doesn't create this problem.

I have done further testing on this. I have this application running on three computers with three IPs (192.168.3.12, 192.168.3.118, and 92.50.13.8). Strangely, this issue only happens on 192.168.3.118. There doesn't seem to be a logical connection, but I thought there might be a programmatic reason.

Note that the applications are all the same, just three copies running simultaneously.

@nvaccessAuto

Comment 7 by jteh on 2012-03-14 00:04
Try pressing control+0 to reset page zoom. There is a bug in Firefox (MozillaBug:650241, fixed in Firefox 13) where location information is often incorrect when the page is zoomed. You may have accidentally zoomed the page at some point.

Also, check whether the browser is maximised or restored on the working machines and do the same on the non-working machine.

@nvaccessAuto

Comment 8 by parham (in reply to comment 7) on 2012-03-14 06:47
Replying to jteh:

Try pressing control+0 to reset page zoom. There is a bug in Firefox (MozillaBug:650241, fixed in Firefox 13) where location information is often incorrect when the page is zoomed. You may have accidentally zoomed the page at some point.

Yes, ctrl+0 disabled zoom and now it works perfectly.

Also, check whether the browser is maximised or restored on the working machines and do the same on the non-working machine.

I was accessing all those IPs that I mentioned using the same machine. It works on two of them, and didn't work on the third one. It was because I had zoomed the page when accessing 192.168.3.118, and Firefox remembered this setting. So every time I tried using other IPs, there would be no zoom, but when I opened 192.168.3.118, the zoom would be back.

@nvaccessAuto nvaccessAuto added this to the 2012.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment