Hi, 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: drive.google.com/open?id=1UImV_AfjfbLOGD1rKEhsOpDoRBm4kdT5
Regards, Mihai On Wed, Sep 26, 2018 at 3:24 PM Klaus Espenlaub <[email protected]> wrote: > 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 < > [email protected]> 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 Илья Пащук <[email protected]> >> 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. >> >>
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
