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
