Bug 6193 - (int-149030) Browser: Tap is treated as input even if device was in standby mode (screen off)
: Browser: Tap is treated as input even if device was in standby mode (screen off)
Product: Desktop platform
File System UI
: 5.0:(10.2010.19-1)
: All Linux
: Low normal with 2 votes (vote)
: ---
Assigned To: Marius Vollmer
: file-system-ui-bugs
  Show dependency tree
Reported: 2009-11-15 15:49 UTC by Attila Csipa
Modified: 2010-05-27 02:28 UTC (History)
4 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description Attila Csipa (reporter) nokia 2009-11-15 15:49:34 UTC
Maemo 5, 1.2009.41-10

Wait for the device to enter standby mode (screen off) with an application
running (do NOT use autolock). Try tapping the screen to (re)activate it.

A tap on the screen should (only) exit standby mode.

The tap is propagated to the underlying application. For example if one is
running a browser, you can easily (inadvertently) activate a link by tapping on
a turned off screen.




User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:
Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Comment 1 Donn Morrison 2009-11-15 19:30:38 UTC
Confirming. I was having this issue with Notes. If you have Notes open and
allow the screen to go off, pressing on the screen (within the Notes window)
changes the position of the cursor.
Comment 2 Lucas Maneos 2009-11-16 03:38:25 UTC
Confirming too.  It's also inconsistent: it doesn't happen in the home screen
or dashboard, and it also doesn't happen if the screen is activated by a
Comment 3 Andre Klapper maemo.org 2009-11-17 14:50:34 UTC
Is this also an issue in 1.2009.42-11?
Comment 4 Lucas Maneos 2009-11-17 14:51:44 UTC
Yes, it is.
Comment 5 Andre Klapper maemo.org 2009-12-03 21:46:24 UTC
Attila, does this refer to any other apps than Browser and Notes?

These are two different issues, technically speaking:
  That is int-149030 and is still valid, triggered by System UI
  That is int-143112 and is still valid.

Keeping this report as the initial Browser issue and cloning the Notes issue.
Comment 6 Attila Csipa (reporter) nokia 2009-12-04 23:27:42 UTC
I have not (yet) noticed it in other apps, I'll try and leave open various apps
and see/report back if I run across any that also suffer from this symptom.
Comment 7 Andre Klapper maemo.org 2010-03-02 18:16:32 UTC
This has been fixed in package
which is part of the internal build version
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
Comment 8 Andre Klapper maemo.org 2010-03-15 20:54:05 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).
Comment 9 Andre Klapper maemo.org 2010-05-27 02:28:40 UTC
Bugfix has been reverted due to three regressions introduced by it, so it is
not included in PR1.2 update.
According to internal comments, Nokia management decided that this will most
likely not fix this problem for the update after PR1.2 - Priorities...