onboard can't type into Firefox bookmark dialog

[Steve Payne]

The onboard virtual keyboard doesn't always get the clicks it's supposed to. I can reproduce this by trying to create a bookmark in Firefox. When the bookmark dialogue comes up trying to enter text with onboard fails and (I believe) the bookmark dialogue believes you've clicked outside it and so vanishes.

(If this isn't really what's going on then feel free to rename this bug.)

[Steve Payne (c-launchpad-iamsrp-com)]

The same thing can be witnessed when using the Google search box in Firefox (on the right, by the address box). Start typing and it creates a dropbox with suggestions in it. Tapping onboard causes the dropbox to vanish; dropbox doesn't see the event.

[marmuta (marmuta)]

Yes, the bookmark dialog wasn't accessible for osks since it's inception. It grabs the pointer, which effectively makes it system modal until the click outside. Onboard doesn't get a chance until after the dialog was closed.
Unfortunately this seems to have been a design decision:
https://bugzilla.mozilla.org/show_bug.cgi?id=393509#c36

On the positive side, bookmarks can be edited by other means. Right clicking an entry in the bookmark menu for example. This has been my workaround for a while.

The issue with the search bar closing and ignoring keystrokes was reported before, Have a look at this bug:
https://bugs.launchpad.net/onboard/+bug/905636
I made a couple attempts already, but so far wasn't lucky enough to find a workaround.

[marmuta (marmuta)]

Though, on second thought, right clicking the bookmarks menu won't be easy on a touch screen. The only other option I see is using the bookmarks library, "Show all bookmarks".

[marmuta (marmuta)]

@Chris, Steve asked for the title to be changed, so I did. You're free to change it again, but note that it now doesn't match the bug description. The new title suggests it has become a duplicate of bug #905636. Was that your intention?

[Chris Wayne (cwayne)]

@marmuta, is this specific to the firefox bookmark dialog? I've seen it in several places where there is a drop-down suggestion list (like in the firefox search bar) so I thought a more generic name would be fitting. If this is not the case, please feel free to change it back.

[marmuta (marmuta)]

The problems with bookmark dialog and popup lists are related of course, but the actual text entries behind the lists don't hide, whereas all of the bookmark dialog's entries are gone on click. I see fewer options to fix input into the dialog, that's why I'd rather keep it as a separate bug report. This way at least the popup list report bug #905636 has a chance to get closed. Also specifics in the title help me remember what bug reports are about when I glance over the list. I'd suggest using the following title.

[Steve Payne (c-launchpad-iamsrp-com)]

While I admit that the following is possibly a _terrible_ solution to the problem I will note it for the record.

One could run Xnest an put the WM (Unity) in that, keeping onboard and the Xnest window in the primary X window.

This feels like an ugly, nasty and generally evil hack which is going to have all sorts of unforeseen effects but, there you go. Flame away!

[marmuta (marmuta)]

The general idea isn't a bad one at all. If the keyboard sat somewhere outside the box it could do it's thing without causing side effects, like triggering grabs. We haven't looked into this direction yet, Onboard is for the most part just another desktop citizen.

Unless they already exist on the system, VMs or nested X servers may be overkill, but perhaps there are other ways to cut Onboard off of the rest of the desktop. I've been thinking to try temporarily detaching and re-attaching XInput devices on enter/leave events and have events from physical sources sent exclusively to Onboard. This doesn't seem to make sense on touch-screens anymore, though, no motion events.