Last Comment Bug 649236 - AccessibleObjectFromEvent not working in-process in 64 bit builds
: AccessibleObjectFromEvent not working in-process in 64 bit builds
Status: VERIFIED FIXED
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 1 vote (vote)
: mozilla8
Assigned To: alexander :surkov
:
Mentors:
Depends on:
Blocks: 646484
  Show dependency treegraph
 
Reported: 2011-04-11 22:21 PDT by James Teh [:Jamie]
Modified: 2011-07-20 18:40 PDT (History)
3 users (show)
mick: in‑litmus-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (1.13 KB, patch)
2011-06-28 03:24 PDT, alexander :surkov
no flags Details | Diff | Splinter Review
patch (1.13 KB, patch)
2011-06-28 03:33 PDT, alexander :surkov
roc: review+
Details | Diff | Splinter Review

Description James Teh [:Jamie] 2011-04-11 22:21:16 PDT
AccessibleObjectFromEvent() works fine out-of-process in 64 bit builds. However, in-process, it seems to return an oleacc client accessible instead of a Gecko accessible. I have no idea why this is the case. As far as Gecko is concerned, WM_GETOBJECT should be received and handled the same way, regardless of whether it's in-process or out-of-process.

Marking as unconfirmed because this needs to be tested/verified outside of NVDA code. I'd use Accprobe, but I'm pretty sure it can't do in-context events for 64 bit processes.

Related NVDA ticket: http://www.nvda-project.org/ticket/1454
Comment 1 Michael Curran 2011-06-17 07:14:29 PDT
It seems to be AccessibleObjectFromWindow with the actual problem, though AccessibleObjectFromEvent calls it internally.
A work around has been implemented in NVDA changeset:main,4474 which replaces a call to AccessibleObjectFromEvent with custom code that  sends WM_GETOBJECT, calls ObjectFromLresult, and tries accChild. All the things that I'd think AccessibleObjectFromEvent/AccessibleObjectFromWindow would do normally.
this allows NVDA to render buffers for 64 bit Mozilla Gecko documents.
Although further testing needs to be done to prove this, I don't think this bug can be Gecko specific.
Comment 2 Michael Curran 2011-06-17 21:16:18 PDT
Actually, after further investigation, the bug is Gecko's. when gecko handles WM_GETOBJECT it checks lParam to see if its OBJID_CLIENT: http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#5236
However,  MSDN states in http://msdn.microsoft.com/en-us/library/dd373892%28v=vs.85%29.aspx that the lParam must be cast to DWORD before comparison with one of the OBJID constants as on 64 bit Windows not doing this can cause issues with the sign extension.
My own testing with a custom 64 bit window proc handling WM_GETOBJECT confirms that  the comparison does fail when AccessibleObjectFromWindow is called from 64 bit to 64 bit, but not called from 32 bit to 32 bit or 32 bit to 64 bit.
I do not understand yet why my own custom code I implemented in NVDA which sends the WM_GETOBJECT message manually gets around the bug.
Comment 3 James Teh [:Jamie] 2011-06-19 00:29:00 PDT
Marking as new given Mick's thorough testing and findings.
Comment 4 alexander :surkov 2011-06-28 03:17:09 PDT
(In reply to comment #3)
> Marking as new given Mick's thorough testing and findings.

guys, you've passed more than half of road :) after verbal patch description one step is to upload patch and ask for review ;) Thank you for doing this!
Comment 5 alexander :surkov 2011-06-28 03:24:14 PDT
Created attachment 542408 [details] [diff] [review]
patch
Comment 6 alexander :surkov 2011-06-28 03:33:11 PDT
Created attachment 542409 [details] [diff] [review]
patch

the previous one is wrong
Comment 8 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-06-28 04:16:03 PDT
Comment on attachment 542409 [details] [diff] [review]
patch

Review of attachment 542409 [details] [diff] [review]:
-----------------------------------------------------------------
Comment 9 alexander :surkov 2011-07-14 01:11:02 PDT
landed http://hg.mozilla.org/mozilla-central/rev/62cb7ce43f42
Comment 10 James Teh [:Jamie] 2011-07-20 18:40:32 PDT
Mick verified fixed in Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0a1) Gecko/20110720 Firefox/8.0a1

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