Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase the Mouse Routing Efficiency In Browse Mode #2029

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

Increase the Mouse Routing Efficiency In Browse Mode #2029

nvaccessAuto opened this issue Jan 5, 2012 · 8 comments

Comments

@nvaccessAuto
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant