Onboard

firefox awesome-bar and search popup swallow key strokes

Bug #905636 reported by marmuta
90
This bug affects 18 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Unknown
Medium
Onboard
Fix Released
Medium
Unassigned
ubuntu-nexus7
Confirmed
Medium
Unassigned

Bug Description

Taken from Question #182060:
--- snip
How do I make Onboard work with autocomplete?
For example when entering a term in the Firefox search box, a list of suggestions pops up and then when you click a letter on Onboard it only gets the focus, and the search box suggestions list disappears, but the letter does not get entered... you have to click it again!
So, you have to click every letter twice... except the first one, of course.
--- snap

Revision history for this message
marmuta (marmuta) wrote :

Confirming, since Francesco had mentioned the same problem before.

Changed in onboard:
status: New → Confirmed
Revision history for this message
marmuta (marmuta) wrote :

I think I know what we can do about this. Apparently firefox needs a certain delay between key press and release. The required delay may be system dependent, i.e. the slower the system is in updating the firefox-popups, the longer it has to be.

I can rarely reproduce this here when I consciously try to keep clicks on onboard as short as possible. Normal typing doesn't trigger it for me.

Carlos and Francesco, please try to hold keys down slightly longer when typing in onboard and let me know if this improves the situation. You may want to temporarily disable key repeat in System settings->Keyboard. If it does help we could probably add some minimum delay between key press and release to onboard.

Revision history for this message
Francesco Fumanti (frafu) wrote :

@ marmuta

I am running an i5 CPU here; is your computer that faster that you have trouble reproducing it?

Thanks to your hint about the delay between the key press and key release. Paying attention to it, it seems to me that it is not the press-release delay of the click itself that determines whether the click is accepted or not; it is the press release delay of the preceding click that determines the acceptance of the following click. Or maybe even the press-release delay of the second to last click... It is not clear at all here.

Unfortunately, I am not able to confirm such a pattern even by turning on the hover click and mixing hardware button clicks and hover clicks . But assuming that the press-release delay of the hover click remains always the same, it might help finding a pattern about when the problem occurs.

Revision history for this message
marmuta (marmuta) wrote :

@Francesco
So does it happen with hover click enabled too?

> I am running an i5 CPU here; is your computer that faster that you have trouble reproducing it?
It may not only be a function of CPU speed. The video driver may play a part in it, the size of the places database as well as the number of entries to display in the popup. My places.sqlite is usually rather empty.

Revision history for this message
Carlos Gorian (cagolatru) wrote :

Hi marmuta,

Disabling key repeat did NOT work.

However, holding the keys down slightly longer or typing faster both work. Unfortunately I do not think either is a very good solution for me.

Now, I was not sure where to put the question/bug because it does not only happen with Onboard, I tried other on-screen keyboards and the same thing happens.

Revision history for this message
marmuta (marmuta) wrote :

Thank you both.
I've investigated this further and it appears that not the delay between simulated key press and key release is at issue, it is the the mouse button press and release itself causing this. The click on onboard causes the awesome-popup to close prematurely and to subsequently miss key press events.

Inserting delays between click and key event as I suggested actually worsens the situation. On the bright side, this way I'm able to easily reproduce key strokes getting lost here too.

Sending a wole string of key strokes without intermediate clicking, e.g. as onboard's snippets do, works fine.

Hover click doesn't help as long there is still (simulated) mouse clicking involved, as is the case with mousetweaks.

To me it looks like the fix has to come from firefox. I'll look into filing a bug report.

Revision history for this message
In , marmuta (marmuta) wrote :

User Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111210141108

Steps to reproduce:

Running Firefox 8.0/9.0 on Ubuntu 11.10 or 12.04
1) Start on-screen keyboard, e.g. Onboard, Kvkdb, probably any will do
2) Click the url bar
3) Type "aaaa" with the on-screen Keyboard

Actual results:

The url-bar shows "aaa", one letter is missing in this example.
Multiple key-strokes may go missing when typing any other sequence.
For example, typing www.slashdot.org gives www.lsdot.org or www.sashdot.org.

Expected results:

The url bar should show "aaaa", four letters.

Revision history for this message
In , marmuta (marmuta) wrote :

Original bug report for Onboard on launchpad:
https://bugs.launchpad.net/onboard/+bug/905636

Revision history for this message
In , marmuta (marmuta) wrote :

If anyone has ideas what can be done about this from Onboard's side, please let us know. I'm at a loss currently, though ready and willing to add workarounds.

Revision history for this message
marmuta (marmuta) wrote :

upstream bug report here:
https://bugzilla.mozilla.org/show_bug.cgi?id=715480

Revision history for this message
Francesco Fumanti (frafu) wrote :

The problem might be more widespread than initially assumed: in fact, today I had the same problem while entering tags into Shotwell, the default picture organizing application shipping with Ubuntu.

Revision history for this message
marmuta (marmuta) wrote :

Francesco, are you sure this is the same bug? There seems to be no popup involved in shotwell tags. I'm not able to reproduce lost key-strokes either, can you give some more details about what happens? Are key-strokes lost when you use snippets too?

Revision history for this message
marmuta (marmuta) wrote :

Yes, shotwell tag editing is affected too, Thanks Francesco.

Revision history for this message
David López (david-lopez-upct) wrote :

Thunderbird 10 is also affected (the search box opened with Ctrl+K now searchs in the web)

Revision history for this message
David López (david-lopez-upct) wrote :

Epiphany browser is also affected

Revision history for this message
Felix Haller (felixhaller) wrote :

no prob on chromium. they have such a search bar too.

Revision history for this message
In , philip wagner (kingofhardcore1992) wrote :

i have notice said issue in firefox 15 alpha i konw that its more the internet connection locking up or your cpu ocking up firefox needs to use more python coding in all versions to improve their cpu usage that way it reduces load time and cpu usage and this bug will stop happening on any os

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
In , Jbecerra-mozilla (jbecerra-mozilla) wrote :

marmuta, are there any key-strokes dropped when typing in other text fields?

Revision history for this message
In , marmuta (marmuta) wrote :

Yes, it's not restricted to firefox. It seems to happen in all Gtk-3 text entries that, on typing, pop up helpful lists to choose from. This became gradually clearer only after I filed this bug report. Firefox is heavily used though, so it's particularly noticed there.

What I use to tell people is to disable the awesome popup while working with Onboard. We don't have a better workaround yet, unfortunately.

One thing I tried was, instead of sending fake key strokes, to insert text directly into the url bar via AT-SPI. However the url entry doesn't seem to support the editable interface, atspi_editable_text_insert_text() did nothing (works in e.g. gedit though).

Revision history for this message
Chris Wayne (cwayne) wrote :

Confirming this on the ubuntu-nexus7 project.

Changed in ubuntu-nexus7:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
marmuta (marmuta) wrote :

I believe we can consider this bug fixed now. Onboard trunk by default listens to XInput slave devices for pointer input, which gets around a number of pointer grab issues, including this bug.

The changes were quite invasive, but we've been testing for a month now, and there are no more known regressions (e.g. worst case bug #1095508). Testing was done on the Nexus 7 and various PC hardware.

In case anything goes very wrong*, the old way of receiving pointer events is still available:
set Preferences->Keyboard->Advanced->"Input event source" to "GTK", no restart required.
Doing so returns this bug, though. Please open a bug report if you have to resort to this.

* For example: clicks/taps/dragging/hover click do nothing, or more or less subtly do the wrong thing.

Changed in onboard:
status: Confirmed → Fix Committed
importance: Undecided → Medium
Revision history for this message
David López (david-lopez-upct) wrote :

Tested trunk 1276 on a wetab tablet with 64 bits archlinux. The issue has gone in firefox with the 'xinput' option enabled. Thanks.

Revision history for this message
Francesco Fumanti (frafu) wrote :

Hi,

I have uploaded a snapshot of the current development status of Onboard containing a fix for this bug and other new features to our main PPA:
https://launchpad.net/~onboard/+archive/ppa

The snapshot is available for raring and for saucy.

Have a nice day.

Francesco Fumanti (frafu)
Changed in onboard:
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: New → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.