Bug 6193 (int-149030)

Summary: Browser: Tap is treated as input even if device was in standby mode (screen off)
Product: [Maemo Official Platform] Desktop platform Reporter: Attila Csipa <attila.csipa>
Component: File System UIAssignee: Marius Vollmer <marius.vollmer>
Status: REOPENED QA Contact: file-system-ui-bugs
Severity: normal    
Priority: Low CC: andre_klapper, attila.csipa, donn.morrison, maemo
Version: 5.0:(10.2010.19-1)   
Target Milestone: ---   
Hardware: All   
OS: Linux   

Description Attila Csipa (reporter) nokia 2009-11-15 15:49:34 UTC
SOFTWARE VERSION:
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.

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

ACTUAL OUTCOME:
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.

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.15)
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
keypress.
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:
BROWSER:
  That is int-149030 and is still valid, triggered by System UI
NOTES:
  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
osso-systemui-tklock 0.2.2.8+0m5
which is part of the internal build version
10.2010.08-19
(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
update.)
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
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
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...