maemo.org Bugzilla – Bug 5694
Application Manager moves to background after start when quickly clicking
Last modified: 2010-03-04 09:59:25 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
1. Launch App. manager
2. Quickly tap one of the option buttons as soon the application opens
Either nothing, or the application remains visible.
Application disappears for a couple of seconds (back to desktop), after which,
it reappears. I've even gotten it to perform its actions (e.g., refreshing the
packages) over the desktop rather than within the application UI, but I can't
reproduce that consistently.
i was about to report this issue as well. i can always reproduce the "fast tap
- throw back to desktop - reappear again" but have not stumbled upon performing
actions over the desktop.
I've also seen this in 41-10, but cannot see it anymore in 43-9...
I think I've even seen a internal bug report about that a week ago but of
course cannot find it anymore, grumble...
I'm going to set this to moreinfo. I *think* that it is FIXED, if you have
progress to the latest builds would be cool to confirm, otherwise I'll check
again in a week or so.
Created an attachment (id=1491) [details]
Screenshot of funky business
I understand this is this most likely fixed in the upcoming firmware, but I
thought I'd attach an example of the HAM functioning over the desktop (and
Yes, I have seen this too. But it isn't a problem in the application manager.
It happens to other applications using the "screenshot cheat" (view mailing
list for information), at the moment: XTerminal and Settings.
In the App Manager is more visible because the start is slower.
Let's to hope this is fixed.
*** Bug 5967 has been marked as a duplicate of this bug. ***
note that you don't necessarily need to "quickly click" anything. you can also
let the app load, and then just hit a key on the keyboard, it will go in the
background, do a contacts search and then come back
During the screenshot transition, in the first update version (so, current
master), we are consuming click events until control is given to the
application itself. So, should be already fixed. Feel free to verify as such
when the update is delivered to your door.
Andre. Feel free to verify this on the PR1.1 release and close.
(In reply to comment #7)
> Andre. Feel free to verify this on the PR1.1 release and close.
Internal ticket (see Alias) has not yet been released/verified internally...
This has been fixed in package
which is part of the internal build version
(Note that 2009 is the year and the number after is the week.)
Any public update released with or after this build version will include the
Please verify that the 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.
*** Bug 6243 has been marked as a duplicate of this bug. ***
The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
I can still make this happen in PR1.1 (actually, it happens for all sorts of
apps during startup).
I noticed it on 1.2009.42-11.002.
With 2.2009.51-1.002, it appears fixed for the app manager.
(In reply to comment #12)
> I can still make this happen in PR1.1 (actually, it happens for all sorts of
> apps during startup).
Tim, where exactly do you click? I'm still unable to reproduce this...
definitely fixed in pr1.1.1 and 1.2.