582269 - onKeyUp for KEYCODE_BACK handled incorrectly when keydown was in another activity

Status: RESOLVED FIXED

(Core Graveyard :: Widget: Android, defect)

Description

[Matt Brubeck (:mbrubeck)]

Steps to reproduce:
1. Open Fennec.
2. Long-press the Home key and switch directly to another app.
3. Press the Back key in the other app.
4. After Fennec reappears, release the Back key.

Expected results: Nothing happens.
Actual results: Fennec goes back (or closes/hides the tab if it can't go back).

nsWindow::mSpecialKeyTracking does not prevent this, because it gets set on any keydown event (not just the initial keydown).  The Android browser works around this by using startTracking() only when getRepeatCount() returns 0: http://android.git.kernel.org/?p=platform/packages/apps/Browser.git;a=blob;f=src/com/android/browser/BrowserActivity.java;h=5e557893b5b61976ea23860e0d52fc14f1644a82;hb=HEAD#l2073

Comment 1

[Matt Brubeck (:mbrubeck)]

Attachment: patch

This patch fixes the bug.  Also includes the search button fix from bug 575351, since this patch required most of that fix too.

Note: I've discovered that the steps to reproduce do not work with most apps, which wait until onKeyUp for the back button action.  I first noticed the bug with the http://www.onebusaway.org/ app, which uses onKeyDown for the back button.  So maybe this is really a bug in OneBusAway, that we don't need to fix in Fennec.

Comment 2

[Michael Wu [:mwu]]

Comment on attachment 460572 [details] [diff] [review]
patch

Getting rid of mSpecialKeyTracking? mbrubeck++

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

fix is in hand and it looks block-worthy for alpha 1

Comment 4

[Matt Brubeck (:mbrubeck)]

http://hg.mozilla.org/mozilla-central/rev/3d786e54c7db