Screen behavior on headphones plug in and navigating to the launcher [released]

Question

9

Screen behavior on headphones plug in and navigating to the launcher [released]

Tracked by Jolla (In release)

asked 2016-05-25 23:28:04 +0300

kandelabra
2784 ●61 ●91 ●95

updated 2016-05-26 23:00:45 +0300

On headphones plug in screen turns on. One goes to launcher screen to start music player (swipe bootom edge scroll launcher and/or browsing apps groups). After few seconds screen goes off again and devices became locked - even right under one's finger touch. It seems that screen timeout is not reset on interaction with the launcher.

Expected behavior:

headphones plug in -> screen goes on -> timeout started -> no user action -> screen goes off after timeout;
headphones plug in -> screen goes on -> timeout started -> any user action -> timeout reset.

By user actions I do not mean just tap lock screen but any meaningful actions, user input.

edit retag flag offensive reopen delete

The question has been closed for the following reason "released in a software update" by Alex
close date 2017-10-12 18:33:07.365725

Comments

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 +0300 )edit

Sorry 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 +0300 )edit

Confirmed! 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 +0300 )edit

Tried 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 +0300 )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 +0300 )edit

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 +0300 )edit
Sorry 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 +0300 )edit
Confirmed! 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 +0300 )edit
Tried 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 +0300 )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 +0300 )edit

Answer 1

3

answered 2016-05-27 18:45:43 +0300

spiiroin
13237 ●151 ●224 ●199

moderator

updated 2017-10-12 18:32:45 +0300

Alex

10635 ●181 ●247 ●252

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.

edit flag offensive delete publish link

Comments

1

I would have agreed with your answer initially... But it turns out you can pull up the "app drawer" (above called "launcher") from the lock screen without swiping either left or right. This does not cancel the re-locking. Whether the "app drawer" being available from the lock screen is a feature or a bug; no idea. I also had no idea this was possible until i tried verifying this bug report.

attah ( 2016-05-27 18:58:44 +0300 )edit

It's certainly not due to not changed lockscreen status because the screen was turned off by power button (I guess it activates lockscreen). So headphones were plugged in locked phone.

In addition to attah's comment I can repeat: It's absolutely natural to go to the app drawer just after plug in headphones to launch your player. So access to app drawer from locksreen should be disabled or considered as unlock. I guess it's not likely that app drawer can be pulled out by accident so it's better to consider it as unlock action.

BTW the same behavior is observed on power button press.

kandelabra ( 2016-05-27 23:42:16 +0300 )edit

@kandelabra I can't reproduce the issue with unlocking by either double-tap or button, only by plugging in headphones.

attah ( 2016-05-28 00:05:57 +0300 )edit

4

@kandelabra Now I got what you meant. Somehow I have forgotten that you can access the apps from lockscreen via bottom swipe too. And it looks like doing that does not cancel the "in lockscreen" state until an application is actually launched -> normal "device is in active use" timeouts (30 seconds by default) do not apply. The difference is that double tap + swipe from botton blanks in 10 seconds, while insert headphones + swipe blanks in 3 seconds. The latter is just more likely to cause annoyance.

I'll file a ticket about this.

Meanwhile note that you can adjust the headphone blanking timeout from command line, for example to use 5 seconds delay instead of the default 3 seconds:

 mcetool --set-exception-length-jack-in=5000

spiiroin ( 2016-05-28 10:13:30 +0300 )edit

Screen behavior on headphones plug in and navigating to the launcher [released]

The question has been closed for the following reason "released in a software update" by Alex
close date 2017-10-12 18:33:07.365725

Comments

1 Answer

Comments

Question tools

Stats

Related questions

Screen behavior on headphones plug in and navigating to the launcher [released]

The question has been closed for the following reason "released in a software update" by Alex close date 2017-10-12 18:33:07.365725

Comments

1 Answer

Comments

Question tools

Public thread

Stats

Related questions

The question has been closed for the following reason "released in a software update" by Alex
close date 2017-10-12 18:33:07.365725