maemo.org Bugzilla – Bug 6193
Browser: Tap is treated as input even if device was in standby mode (screen off)
Last modified: 2010-05-27 02:28:40 UTC
You need to
before you can comment on or make changes to this bug.
Maemo 5, 1.2009.41-10
STEPS TO REPRODUCE THE PROBLEM:
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.
EXTRA SOFTWARE INSTALLED:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168)
Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
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.
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
Is this also an issue in 1.2009.42-11?
Yes, it is.
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.
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.
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
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).
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...