maemo.org Bugzilla – Full Text Bug Listing
|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 UI||Assignee:||Marius Vollmer <marius.vollmer>|
|Priority:||Low||CC:||andre_klapper, attila.csipa, donn.morrison, maemo|
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: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 keypress.
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: 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.
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 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/
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...