Eero Tamminen wrote:
Thanks, I could reproduce it now. I need to press Back and Menu keys
very quickly after each other.
Exactly! :)
If I press them slowly this doesn't happen.
Agreed.
And it doesn't seem to happen if I cancel the menu with another
keypress, I don't know why.
Actually, it does happen if the menu is "cancelled" with another keypress. For
example, the Home key will Close the application (eg. Opera) if the key is pressed while
the menu is visible.
I've succeeded in causing the bug (ie. app to close) with the following
combinations:
1. Back+Menu followed by Menu keypress
2. Back+Menu followed by Home keypress
3. Back+Menu followed by stylus/finger event
4. Back+Menu followed by Power keypress
5. Back+Menu followed by removal of battery cover ("Memory card in use" dialog
steals focus from Menu)
Basically, any event that causes the menu to lose focus will result in the
application closing.
My assumption on what happens:
- Back key pressed -> ESC press delivered to application
- Back key released & menu pressed -> Menu opens before application
window processes the ESC release
- Only after the menu goes away with a tap, the ESC release is processed
by the application window. As the interval between processing the
press and release events was long, it's interpreted as a long press
I suspect your assumption is entirely correct - the ESC release is being
delivered to the application after the menu is dismissed and thus interpreted
as a long keypress.
I'm not sure how this could be fixed. The X events contain a timestamp,
maybe this could be used for checking the event interval instead of
the interval of processing the events.
I can't suggest a fix, but using the timestamp sounds like a possible solution,
or having the events delivered in the correct sequence may be the correct fix -
I'm pretty sure I'm releasing the Back key before the Menu key is pressed so
the Back press/release events should be delivered to the application before the
Menu press/release event is generated (or queued).
Currently the bug seems to have 0 votes. Are the other users pressing
the keys in a way that triggers this bug too? (I don't think I've ever
triggered this mysefl when using the device)
I'm not really sure the 0 votes is indicative of anything, to be honest. Other
users, if they experience this problem, may be unfairly attributing the problem
to the application in use at the time the bug occurs.
Speaking personally, I've caused this situation several times (hence the bug in
my name!) Maybe I'm more prone to cause this problem due to my fat fingers/big
hands/whatever, however the design of the buttons (ie. being so close together)
ensures this situation is likely to happen for many people and not just me. And
and once the menu has been invoked due to the combination keypress, it's almost
impossible to backout of the situation without concious effort on the part of
the user.
> The particularly annoying aspect of this bug is that it can and does
> occur when you least expect it, thus giving the impression the
> application has just crashed when the application isn't at fault, it's
> the OS/desktop/haf/core that has erroneously closed the application.
Indeed...
- Eero
Neil
_______________________________________________
maemo-users mailing list
maemo-users@maemo.org
https://maemo.org/mailman/listinfo/maemo-users
