[vbox-dev] getting object name in VirtualBox gui

Mihai Hanor quake2iasi at gmail.com
Wed Sep 26 17:12:14 UTC 2018


There's a difference between the VirtualBox Manager window and the VM
window, to which I was referring to. Here's how VirtualBox (latest 5.x test
version) is behaving with the Narrator, on Windows 10 1803 64 bit:


On Wed, Sep 26, 2018 at 3:24 PM Klaus Espenlaub <klaus.espenlaub at oracle.com>

> Hi Mihai,
> On 25.09.2018 20:21, Mihai Hanor wrote:
> Hi Klaus,
> When you say that the devs have been working on it, are you referring to
> the 5.2.18 release build, the testing builds or the svn? I've build today a
> svn on Windows 10 and the Windows Narrator is not able to read the VM
> window menu controls. All I hear for it is "pain"/"main" or something
> similar, I'm not sure what it's saying. It's only able to read the VM
> window title. The same thing happens with 5.2.18.
> The work on accessibility has been during the 5.2 development mainly
> (requiring a new approach since Qt5 manages accessibility quite differently
> than Qt4). And one of our GUI devs just confirmed that both Microsoft
> Narrator and NVDA do a reasonable job with reading the majority of the
> manager UI (which has been the topic so far) from the latest 5.2.19 test
> build (actually a more recent one which isn't available publicly, but there
> were no significant changes in a while). "Reasonable job" means that
> they're correctly reading the text for UI elements where the mouse cursor
> is hovering.
> So we'd need more details about what aspect of accessibility isn't
> behaving adequately.
> From my perspective (building VirtualBox and crashing things), the fact
> that the OS or the debugger are unable to get a "handle" on the hardened
> process, it's something missing. WER just lets the process exit, because it
> can't attach to it. Windbg also can't attach to the process. I'm only able
> to save a dump when there's no default debugger, when the OS puts a message
> box that the process has crashed, then I start Process Explorer as admin
> and dump the process. I haven't found a way to do automatic process memory
> saving. That's the experience I remember, because I haven't had a crash in
> some time. A build-in crash handler could help users report crashes, it
> could be useful.
> Debuggers simply have no business in a process doing virtualization work
> (just like random, untrusted DLLs which some applications inject into every
> executable, some of them totally destroying any remaining bit of security,
> interestingly mostly done by apps promising to increase security). They
> could corrupt the state of the VM which can end up trashing kernel memory,
> i.e. being a security issue. So this "loss" is entirely intentional (i.e.
> that the VM process handle which is passed to other parties is seriously
> stripped down). It's a different question what to do for post-mortem
> dumping, because at that point the VM is already effectively dead. But IIRC
> Windows adds a new thread to it, kind of bringing it partially back from
> the dead. Which would again end up being questionable from the security
> perspective.
> Klaus
> Regards,
> Mihai
> On Tue, Sep 25, 2018 at 8:52 PM Klaus Espenlaub <
> klaus.espenlaub at oracle.com> wrote:
>> Wait... is it really confirmed that Narrator can't work with (hardened)
>> VirtualBox either? That would mean our devs must have been testing the
>> wrong thing for quite a while now. It certainly hasn't reached my attention
>> so far.
>> For many reasons we cannot recommend that random people run non-hardened
>> builds. What might be a way out (not with the current builds, they would be
>> affected by hardening) is to ship an additional compilation of the VM UI
>> which is not subject to hardening and can be used solely with the "separate
>> VM/UI process" option which VirtualBox has already. Would bring some minor
>> feature losses, but if that would bring back full accessibility I can see a
>> good justification for spending the necessary time.
>> Klaus
>> On 25.09.2018 19:26, Mihai Hanor wrote:
>> Hello,
>> I'm not a developer, but I have some experience with VirtualBox. The
>> reason why not even Microsoft's narrator is able to work with VirtualBox is
>> the hardening of the VirtualBox process, which is enforced to protect the
>> VM from eavesdropping (I think). You can look at the VirtualBox SDK, but
>> you'll probably not find what you're looking for. Also, integrating the
>> NVDA client controller is probably not going to happen and it doesn't look
>> useful, because it requires VirtualBox to send stuff to NVDA (by looking at
>> the C example), which would require considerable effort to rewrite the GUI.
>> The most achievable task might be to build VirtualBox OSE for Windows,
>> without hardening. A much harder task would be to separate the the
>> frontend/GUI part from the VM process and make the frontend run in a normal
>> process. In the upcoming major release of VirtualBox, it looks like the
>> devs have made a move to separate the VM process, but I'm don't know to
>> what end. The frontend still runs in a hardened process.
>> Regards,
>> Mihai Hanor
>> On Fri, Sep 21, 2018 at 12:30 PM Илья Пащук <ilusha.paschuk at gmail.com>
>> wrote:
>>> helo.
>>> I'm a nvda (nvaccess.org) screenreader addon developer
>>> I need the way to get some object text in vbox gui, that unaccessable by
>>> standard methods.
>>> are there any api interface to get this info from vbox gui?
>>> i'm using python.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20180926/f24b6688/attachment-0001.html>

More information about the vbox-dev mailing list