answered
2016-05-27 18:45:43 +0200
Touchscreen events are not considered as "activity that should keep the display on" when lock screen is active. One reason for this is that it allows display to blank faster if it has been accidentally turned on in pocket (stray events from capacitive touch through cloth do not keep the display on indefinitely) i.e. like @attah suggest: swiping away the lock screen is needed first.
However, there is a slight problem if device lock code is used. In sfos 1.x the lock code was entered after swiping the lock screen away -> normal blanking rules apply. While in 2.x unlocking happens in the context of lock sreen -> currently lower level sw has no way to tell apart random taps from user entering the lock code -> if you are not fast enough, the display can get blanked while entering the lock code. (This particular issue has been raised internally too)
Alternatively: If you plug in headphones after display has dimmed & blanked, but lockscreen has not been activated yet when the cable is connected -> due to there not being any lockscreen state changes, the reason for display wakeup remains at "headphones plugged in" and activity just postpones the blanking by couple of seconds (normal blanking rules do not get activated). Maybe this is what you saw?
EDIT 21-06-2017:
Should be fixed in sfos 2.1.2 - Switching to lock code entry view or otherwise exiting the "plain lockscreen" view cancels shorter than normal blanking timeouts related to notifications / alarms / etc.
Edit:
This bug has been fixed with SailfishOS 2.1.2.3.
I can't reproduce... (I think?) If you swipe away from the lock screen it works as expected. One might think of the plugging in action as replacing pushing the power button. If you mean that "any user action" should include things that don't start with swiping away the lock screen, I respectfully disagree with your expectations. Or do you mean using the media controls? In that case I kinda agree that the timeout should be reset. (Isn't it?!)
attah ( 2016-05-26 00:40:57 +0200 )editSorry guys, I missed some details. This bug occurs only when I open the launcher screen. It's absolutely natural to go to the launcher just after plug in headphones to launch your player. Timeout is reset only on player launch, but it doesn't on navigation launcher screen, including groups browsing.
kandelabra ( 2016-05-26 22:53:39 +0200 )editConfirmed! Swiping up the app drawer does not cancel the timeout. Swiping to either side, however, does. Have an upvote!
attah ( 2016-05-26 23:17:13 +0200 )editTried again with your updated details, still cannot reproduce the problem. Headphones in from standby -> screen comes on -> flick up launcher -> get on with task.
Spam Hunter ( 2016-05-27 14:10:10 +0200 )edit@Markkyboy Ok, here is the video, even without headphones, power button causes same behavior:
https://yadi.sk/i/xaMtgwkNs4uFM
kandelabra ( 2016-05-27 23:56:39 +0200 )edit