Bug 5982 - (int-154335) Phone unlocked when receiving call
(int-154335)
: Phone unlocked when receiving call
Status: RESOLVED FIXED
Product: System software
general
: 5.0/(3.2010.02-8)
: N900 Maemo
: Low major with 68 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: system-software-general-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-11-01 12:45 UTC by Karlo Luiten
Modified: 2011-02-11 08:40 UTC (History)
34 users (show)

See Also:


Attachments
N900 unlocks the screen itself when receiving a call (30.08 KB, image/pjpeg)
2010-06-19 11:23 UTC, redex
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Karlo Luiten (reporter) 2009-11-01 12:45:24 UTC
SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
 Receive a call

EXPECTED OUTCOME:
 I expected to see the person who calls me, have to unlock the phone and then
answer the call

ACTUAL OUTCOME:
 The phone is already unlocked when receiving a call, resulting in accidental
hanging up a call.

REPRODUCIBILITY:
 Always 

OTHER COMMENTS:
 Having to unlock the phone first would help, because it's easy to press a
button accidentally in your pocket.

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3)
Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3
Comment 1 Olivier Crête 2009-11-01 13:38:03 UTC
One possible solution to this problem is to have a on-screen slide instead of
the answer and reject buttons.
Comment 2 Karlo Luiten (reporter) 2009-11-01 14:24:06 UTC
Would be helpful, yes.

I have rejected about half the calls I receive. This really is a problem for
me.
Comment 3 Andre Klapper maemo.org 2009-11-01 17:32:30 UTC
I assume that this is not about Device lock, but about the 'Touch screen and
keys' (T&K) lock.

Nokia currently has no plans to change the current behaviour for Fremantle.
Please note: Though this is a WONTFIX for Maemo5 it does not mean that Nokia
does not take this request into account for future Maemo planning.

In any way, feel free to vote for this bug.
Comment 4 Ryan Abel maemo.org 2009-11-09 21:08:13 UTC
(In reply to comment #0)
> OTHER COMMENTS:
>  Having to unlock the phone first would help, because it's easy to press a
> button accidentally in your pocket.
> 

As far as I'm aware, the proximity sensor handles preventing pocket-answers. .
. .
Comment 5 Andre Klapper maemo.org 2009-12-04 01:29:50 UTC
*** Bug 6552 has been marked as a duplicate of this bug. ***
Comment 6 Kasper Souren 2009-12-04 12:19:56 UTC
I've lost many calls because of this behaviour and I'm baffled to see there are
no plans to fix this!

This is not something reviewers will pick up in the beginning but customers do
get upset when they notice they regularly loose phone calls.  I really think
Nokia should fix this, or at least provide an option.


"As far as I'm aware, the proximity sensor handles preventing pocket-answers."

It doesn't do that well enough and I've also rejected phone calls in the
grabbing action when the phone was already out of my pocket.
Comment 7 Naba Kumar nokia 2009-12-04 16:15:00 UTC
(In reply to comment #6)
> 
> "As far as I'm aware, the proximity sensor handles preventing pocket-answers."
> 
> It doesn't do that well enough ...

It's suppose to work. If it isn't then that should be fixed.
Comment 8 Olivier Crête 2009-12-04 16:27:13 UTC
The proximity sensor should be set to like 5-10cm at least for the pocket case
(think of women who care their phones in their purses and stuff). I still think
we should have a slider like the iPhone does.
Comment 9 Naba Kumar nokia 2009-12-04 16:37:38 UTC
(In reply to comment #8)
> The proximity sensor should be set to like 5-10cm at least for the pocket case
> (think of women who care their phones in their purses and stuff). I still think
> we should have a slider like the iPhone does.
> 

I checked. It seems to have about 1 cm threshold. I think 5-10 cm is too much
for this and could lead to other side-effects. IMO, it should also have a
timeout after the obstacle has gone. This could prevent some of the "handling"
part after the phone is removed from pocket.
Comment 10 Kasper Souren 2009-12-04 16:43:33 UTC
A timeout of 2 seconds seems appropriate.

Is there a way to change the distance setting on the phone in some file in /etc
or so?
Comment 11 Naba Kumar nokia 2009-12-04 16:46:37 UTC
(In reply to comment #10)
> A timeout of 2 seconds seems appropriate.
> 
> Is there a way to change the distance setting on the phone in some file in /etc
> or so?
> 
Lassi would know a person to answer that. Adding him in CC.
Comment 12 Andre Klapper maemo.org 2009-12-22 16:20:45 UTC
*** Bug 7218 has been marked as a duplicate of this bug. ***
Comment 13 Gregor Schaffrath 2009-12-22 17:27:00 UTC
Hm - afaik, you've got a 'slider' concept (at least you're using it for the
display lock) - would it really be a hassle to e.g. replace the two buttons by
sliders?
IMO, the accidental call acceptancy/rejection issue is really a problem for the
use of the N900 as a phone...
Comment 14 Janne Hyvärinen 2009-12-25 12:32:21 UTC
This happens to me too and it is really starting to be annoying. I sometimes
answer the calls, sometimes reject them and sometimes even manage to flip to
homepage without even seeing the caller or what had happened.
The phone needs slide action to answer or reject calls or it is useless for me.
Comment 15 Andre Klapper maemo.org 2009-12-28 14:13:57 UTC
As written before, Nokia has decided that this is WONTFIX. Hence closing again.
Comment 16 Karlo Luiten (reporter) 2009-12-29 13:08:32 UTC
Please vote for this bug, maybe nokia will look at it again.
Comment 17 Andre Klapper maemo.org 2010-01-04 00:19:35 UTC
*** Bug 7602 has been marked as a duplicate of this bug. ***
Comment 18 dave 2010-01-04 12:59:53 UTC
Nokia keep closing this bug but it keeps coming up again and again. The comment
on closing it is that the proximity detector takes care of it but there is a
major flaw with that argument. Asyou take the phone out of your pocket the
detector clears your pocket first and turns on the touchscreen which then
rejects your call etc.
The second problem is that this have lead to an inconsistant UI. If the
detector is good enough for the phone app why is it not good enough for the
unlock screen where nokia have implemented a swipe to unlock. Please vote for
this bug
Comment 19 flinkeKoralle 2010-01-13 17:21:23 UTC
Same here. Here is how you can reproduce it really easy:

Place your phone in portrait with "earphone-jack" side pointing upwards into a
jacket pocket. When you receive a call and grab your phone with the thumb on
screen the call will be rejected in most of the cases.

Slider would be a good replacement!

Workaround: Put your phone always upwards (USB jack up) in your pocket.
Comment 20 Max Edin 2010-01-13 17:22:51 UTC
This happends to be each time I answe a call and am outside. I always listen to
music and hence, I have my phone in my pocket with the headphones jack up.
Almost every time I recieve a call I accidentaly hang up. This is getting
pretty iritating.
Comment 21 Fredrik Wendt 2010-01-13 17:45:27 UTC
I'd just like to confirm that flinke's suggested "hardware" workaround works
pretty well.

Perhaps the source of the booklet that comes with the phone could be open
sourced so we could provide a patch to it: Please place your phone with the USB
socket pointing towards the pocket's entry hole, to avoid rejecting phone calls
by accident when taking the phone out of your pocket. :)
Comment 22 Frederik Niedernolte 2010-01-15 00:20:51 UTC
Slide to the left -> Accept call
Slide to the right -> Deny call

Simple as that and much safer (also looks fancy)
Comment 23 EC 2010-01-19 18:15:57 UTC
I've never experienced problems like those you are telling. When the phone is
vibrating and sounding in my pocket, the proximity sensor keep it locked until
I take it out, and then I can check the caller and choose to accept/refuse the
call. Maybe if you usually carry your phone in a bag the proximity sensor can't
work properly, as it is setted to a very close distance (proper for a pocket,
bad for a bag). In that case the possibility to use the "Swap to answer" or any
other solution you have proposed should be optional: you may need it, I don't. 
However, I'm voting for this bug, Nokia has to do something because not
everyone is satisfied by its UI.
Comment 24 flinkeKoralle 2010-01-19 21:32:24 UTC
(In reply to comment #23)

Hi Emanuele,
when the phone is IN the pocket there is no problem. It's when you take it out!
If you grab the phone like most of us (thumb on screen and fingers on the back)
you will have the thumb on the cancel button. As soon as the cancel button is
released, the phone call is rejected.
Use a pocket (e.g. your jeans) and follow my instructions above (see #19) to
try it out!


Frederik (#22)

nice idea!!!! sounds cool !!
Comment 25 Arsalan 2010-01-19 22:18:57 UTC
flinkeKoralle described the issue perfectly. This should be addressed ASAP
because it is annoying as hell.
Comment 26 Andre Klapper maemo.org 2010-01-19 22:26:59 UTC
"me too" comments are unhelpful and create noise. Please use the forum at
http://talk.maemo.org instead, as this is a bugtracker and hence a bit
different. With every comment you create bugmail, and if you want developers to
read what you write then please reduce comments to important and helpful stuff.
Comment 28 redex 2010-01-19 23:22:37 UTC
There is already a Brainstorm for this Issue.

It's more common and points at the complete UI when the Device unlocks itself.

We have not only a problem with calls, we have a problem with all events that
unlock the device themselves.

Here is the Brainstorm: 
http://maemo.org/community/brainstorm/view/actions_when_device_is_locked_and_a_event_like_aleart-alarm_or_call_happens

Here is the Discussion at Talk: 
http://talk.maemo.org/showthread.php?t=40872
Comment 29 Andreas Nyholm 2010-01-20 10:04:03 UTC
I did some tests with the proximity sensor and I see two problems. 

1. The distance for me is about 5-10mm, I think this could be 20-30mm without
leading to side effects.

2. The more important issue I noticed is how the sensor and button press is
handled. This issue makes it a valid bug imo.

Test case with PR 1.1:
- Make a call to the phone and before the phone is ringing put one thumb over
proximity sensor and the other thumb where the red hang up button will appear.

- When phone is ringing first remove thumb from proximity sensor, then remove
thumb from hang up button.

The outcome from this test case is the call is rejected. I think a keypress
before the proximity sensor is changing state should not be valid. The user
should first need to release the button and then press again.

3. An addition. A short timeout as Naba Kumar mentioned is also needed. Two
cases:
- Phone in purse -> Sensor changing state several times. Timeout for sensor,
about 1 sec I see appropriate.
- Timeout for valid key press. I see a possible problem when user is holding a
button while removing phone from pocket. If the thumb is just slightly removed
an invalid keypress would be valid. This of course demands that the interface
behaves as I mentioned in 2. This timeout should be no longer than 0.5 sec.

With these three fixes most of us will not have more problems than with normal
phones and no need to change behavior. But I still think the slider to answer
could be a good option (via settings menu) if anyone need a more secure option.

I have not tested but think these fixes are also valid for alarms and alerts
mentioned in brainstorm above.
Comment 30 ZeeD 2010-01-20 11:03:29 UTC
2 redex@ich.ms
I know about that Brainstorm and have voted on this but, as everyone here
knows, Nokia WONTFIX it

I thought may be Nokia will change buttons position at least? 
And add this option as a checkbox in, for example, 
"Settings -> Phone -> User interface -> Put Reject button on the top in
portrait mode during incoming call"
AND/OR
"Settings -> Phone -> User interface -> Split Reject and Answer buttons
vertically in portrait mode during incoming call"

IMHO, it's a little bit easy to rearrange Answer and Reject buttons than add
swipe options and Nokia will compromise to change UI for incoming call,
"split/rearrange buttons".
Comment 31 Andre Klapper maemo.org 2010-01-20 12:29:18 UTC
(In reply to comment #30)
> 2 redex@ich.ms
> I know about that Brainstorm and have voted on this but, as everyone here
> knows, Nokia WONTFIX it

For discussing suspicions please go to a forum like talk.maemo.org. This is a
bugtracker and comments should be reduced on what's helpful.
Comment 32 tdebug 2010-01-25 15:07:14 UTC
Yes, totally agree this is not the place for a big discussions. 

Because, apparently, instead wasting a time for philosophy about Nokia current
plans, somebody may FIX THE BUG! Because customers don't care about current
Nokia plans with Frematle - they care about bugs to be fixed.
Obviously somebody may fix this in even shorter time that "another somebody"
spent answering here.
But, yes, I know you don't care about bugs, so just thanks a lot from another
extremely satisfied customer!
Comment 33 Andre Klapper maemo.org 2010-01-25 15:25:25 UTC
tdebug: Unconstructive rants are not welcome in Bugzilla, because 
1) this is not a forum - feel totally welcome to post that in talk.maemo.org
2) this is maemo.org and not nokia.com. You could contact Nokia Customer Care
3) they create bugmail for everybody, not only for the Nokia folks you wanted 
   to address this to.
Thanks.
Comment 34 Naba Kumar nokia 2010-01-25 15:39:06 UTC
The internal bug which got WONTFIXED was filed on UI design, but as I mentioned
in a past comment, we may still be able to reduce the effect of accidental call
handling by introducing a proximity sensor timeout: comment 9 ?

There are other things mentioned in comment 29 that needs checking (like the
part where you touch both the sensor and screen and getting clicked when
removing sensor thouch). Perhaps we should file a separate internal bug for
that one, but let's see.

So, I have filed an internal bug for proximity sensor guys to evaluate it: bug
154335 and reopening this.
Comment 35 Naba Kumar nokia 2010-01-25 15:54:42 UTC
re-assign to default assignee.
Comment 36 tdebug 2010-01-25 15:56:27 UTC
(In reply to comment #34)
> The internal bug which got WONTFIXED was filed on UI design, but as I mentioned
> in a past comment, we may still be able to reduce the effect of accidental call
> handling by introducing a proximity sensor timeout: comment 9 ?
> 
> There are other things mentioned in comment 29 that needs checking (like the
> part where you touch both the sensor and screen and getting clicked when
> removing sensor thouch). Perhaps we should file a separate internal bug for
> that one, but let's see.
> 
> So, I have filed an internal bug for proximity sensor guys to evaluate it: bug
> 154335 and reopening this.
> 


In my opinion, proximity sensor is not quite thing we need here. There will be
much more useful to implement slider instead of that, that will give a
guarantee against sensor's timeouts etc. User always know better than sensor
when he want to answer or reject a call.

Thanks!
Comment 37 ZeeD 2010-01-25 15:59:18 UTC
2 Naba Kumar
Is it possible, at least, change the Answer and Reject buttons places in
portrait mode during incoming calls?
It is completely inconvenient to operate the phone by one hand and try to hit
Answer button by thumb!
Plase, place this button to the bottom in portrait mode or split the Answer and
Reject vertically as in the landscape mode!
The Answer button must be the lawest button, not the Reject button.
Comment 38 Max Edin 2010-01-25 16:07:06 UTC
(In reply to comment #37)
> 2 Naba Kumar
> Is it possible, at least, change the Answer and Reject buttons places in
> portrait mode during incoming calls?
> It is completely inconvenient to operate the phone by one hand and try to hit
> Answer button by thumb!
> Plase, place this button to the bottom in portrait mode or split the Answer and
> Reject vertically as in the landscape mode!
> The Answer button must be the lawest button, not the Reject button.
> 

Yes, since the slider suggestion is WONTFIX (I can't really understand why)
this should be a simpler fix and might be possible?

Since the 3.5mm jack is at the bottom of the phone and I belive the most common
usage case when listening to music with the phone is to place it in the pocket
with the 3.5mm jack facing upwards from the pocket placing the end call button
at the top of the screen will help with accidentally rejecting calls. 

However a second fix that would remove this problem with rejected calls would
be to move both buttons upwards by the height of the end call button. Since
most often my thumb (or index and middel fingers) would be placed right over
the end call button. Moving them upwards a bit would make my fingers be on
parts of inactive UI.
Comment 39 Gregor Schaffrath 2010-01-25 16:11:07 UTC
While in principle I agree with the slider idea, I think that having a timeout
in the proximity sensor would help as well.

I'd like to put forward, though, that it might make sense to couple the
proximity timer to the conditions of:
 - incoming call and
 - proximity sensor reported near object when the incoming call started ringing
(i.e. the device is in the pocket)

Otherwise I already see people complaining about not being able to use the
dial-menu of their voiceboxes due to the timeout between listening to
announcements and typing on the on-screen dialpad ;)

Cheers for reopening, Gregor. :)
Comment 40 Naba Kumar nokia 2010-01-25 16:22:57 UTC
(In reply to comment #36)
> In my opinion, proximity sensor is not quite thing we need here. There will be
> much more useful to implement slider instead of that, that will give a
> guarantee against sensor's timeouts etc. User always know better than sensor
> when he want to answer or reject a call.
> 
Well, if we solve "phone unlocked when receiving call" bug by some other means,
does it matter? UI change is out of question from the original bug. But if it
is possible to reduce the impact (e.g. people don't spend ages taking out their
phone from pocket), I think that's already quite good.

The timeout also has a benifit when user is talking on the phone placing at ear
and sensor accidentally deactivates when fiddling your arm/phome (e.g. when you
are walking). This also protect from such cases, which surprisingly seem to
happen often.

(In reply to comment #37)
> 2 Naba Kumar
> Is it possible, at least, change the Answer and Reject buttons places in
> portrait mode during incoming calls?

If in the context of this bug, no. As evident from UI change bug (which
actually proposed a better approach then replacing the buttons).

> It is completely inconvenient to operate the phone by one hand and try to hit
> Answer button by thumb!

If in *that* context, even more no :). Operating it by thump isn't considered
big hurdle to bring in that level of change. But frankly, it works quite fine.
There are many phones with buttons at the bottom.
Comment 41 ZeeD 2010-01-25 17:02:47 UTC
>> Is it possible, at least, change the Answer and Reject buttons places in
>> portrait mode during incoming calls?

> If in the context of this bug, no. As evident from UI change bug (which
> actually proposed a better approach then replacing the buttons).

What is the number of the "UI change bug"? Have not found this in this
thread...

>> It is completely inconvenient to operate the phone by one hand and try to hit
>> Answer button by thumb!

> If in *that* context, even more no :). Operating it by thump isn't considered
> big hurdle to bring in that level of change. But frankly, it works quite fine.

Please, wear a glove and try to hit Answer button many times in portrait mode.

> There are many phones with buttons at the bottom.

Is it a hint to think about a phone from different vendor?:)
Comment 42 Naba Kumar nokia 2010-01-25 17:12:57 UTC
(In reply to comment #41)
> 
> What is the number of the "UI change bug"? Have not found this in this
> thread...
> 
It's internal bug int-127243, which I change to the new one int-154335

> 
> Please, wear a glove and try to hit Answer button many times in portrait mode.
> 
We are in Helsinki and it's winter now. You can imagine the rest ... :)

> > There are many phones with buttons at the bottom.
> 
> Is it a hint to think about a phone from different vendor?:)
> 
Nokia had made several phones with call buttons in bottom half of the phone; no
need to go to other vendors :). I use n900 everyday also and it's not that hard
to press the bottom 20% of the screen (that's the amount covered by the button,
approx.). More importantly, let's not morph the bug.
Comment 43 H. Can Celik 2010-01-25 18:39:06 UTC
(In reply to comment #34)
> The internal bug which got WONTFIXED was filed on UI design, but as I mentioned
> in a past comment, we may still be able to reduce the effect of accidental call
> handling by introducing a proximity sensor timeout: comment 9 ?
> 
> There are other things mentioned in comment 29 that needs checking (like the
> part where you touch both the sensor and screen and getting clicked when
> removing sensor thouch). Perhaps we should file a separate internal bug for
> that one, but let's see.
> 
> So, I have filed an internal bug for proximity sensor guys to evaluate it: bug
> 154335 and reopening this.
> 

It's not only the call makes the phone unlocked. How about calendar alarms?
Changing proximity sensor won't really work in this situation. Think about this
example. You put your phone beside your bed and in the morning you try to reach
your phone and snooze the alarm. You accidently tap the "Stop". You'll be late
the work. The slider is actually a perfect solution.
Comment 44 Naba Kumar nokia 2010-01-25 19:07:01 UTC
(In reply to comment #43)
> 
> It's not only the call makes the phone unlocked. How about calendar alarms?
> Changing proximity sensor won't really work in this situation. Think about this
> example. You put your phone beside your bed and in the morning you try to reach
> your phone and snooze the alarm. You accidently tap the "Stop". You'll be late
> the work. The slider is actually a perfect solution.
> 
Calender alarms, or anything else, that automatically bypass screen-lock
without user's consent, should utilize proximity sensor. It's there for a
reason and we should see that it works optimally, if not perfectly.

If you see that current alarms do not respect proximity inhibition when the
device is in locked state, please file a to alarms component. (but don't file
one if it already respects it and you only wish the timeout to work correctly,
which is covered in this bug).
Comment 45 redex 2010-02-01 18:10:23 UTC
(In reply to comment #44)
> Calender alarms, or anything else, that automatically bypass screen-lock
> without user's consent, should utilize proximity sensor. It's there for a
> reason and we should see that it works optimally, if not perfectly.

This will only work perfectly with at _minimum_ 2 proximity sensors. One at the
top left and the bottom right corner. (I would prefer 4 sensors in this case)
But we've got only one proximity sensor at the N900. This works great to lock
the screen during a phone call. But not while pulling it somewhere out. (many
others failed with this try, compare Symbian 5800 XP and N97)

The worst case is to add only a delay time. Then you're sitting in a conference
or the cinema, hitting your touchscreen and swearing because you have to wait
until the touchscreen will response. When you add a delay time, please
implement it with the possibility to snooze the ringtone instantly only by
hitting the screen in the moment the sensor gives the okay. And then unlock the
screen after the delay to answer or reject.


Please don't forget this during the fixing and development. I will search for
alarm and calendar bug reports and create one if none exists. But I would still
prefer a consistent solution with a consistent UI.
Comment 46 Andre Klapper maemo.org 2010-02-02 13:50:59 UTC
*** Bug 8769 has been marked as a duplicate of this bug. ***
Comment 47 Darren Long 2010-02-06 15:05:10 UTC
I have only succeeded in answering the phone once when it is my pocket, in the
Noreve case.  On all other occasions, I have inadvertently rejected the
incoming call.

In order to not reject an incoming call, I have to carefully pull the phone out
of my pocket by gripping the sides and not putting pressure on the the case
front, and hence, on the screen.

When I put my phone in my pocket, it goes in with the power connector pointing
downwards, so I can flip the case open and hit the accept key with my thumb. 
When the phone rings and I pull it out and open the case, the Reject key is
always lit with a yellow highlight, showing that I have rejected the call.

In my opinion, a viable solution is to leave the screen locked, requiring a
flick of the switch to unlock it.  Please don't WONTFIX this.  It is definitely
a problem that needs fixing for the N900, and the sooner the better.

I may have discovered this issue earlier, were it not the fact that my 3 SIM
didn't wotk until the 1.1 update.
Comment 48 Ndi 2010-03-26 18:37:18 UTC
"Then you're sitting in a conference or the cinema, hitting your touchscreen
and swearing [...]"

I find accelerometer to be the best way to shut it up, works as silent for
ringtones and (IIRC) as snooze for alarms (I think, I might have software
installed).

Accelerometer silence works regardless of sensor or lock.
Comment 49 Andre Klapper maemo.org 2010-03-26 18:49:44 UTC
(In reply to comment #48)
> I find accelerometer to be the best way to shut it up

Just turn the N900 with the screen to the bottom and it silences the ringtone.
Comment 50 Andre Klapper maemo.org 2010-03-29 13:15:31 UTC
This has been fixed in package
mce 1.8.114+0m5
which is part of the internal build version
10.2010.12-1
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this 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.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 51 Frederik Niedernolte 2010-03-30 12:19:56 UTC
Thanks for fixing.
How is it fixed and will it be included in the PR 1.2 firmware release?
Comment 52 Andre Klapper maemo.org 2010-03-30 13:55:57 UTC
All we know is written in comment 50. That's it.
Comment 53 redex 2010-04-06 13:54:29 UTC
As discussed here before with some Moderators, Quim Gil and a Community Council
http://talk.maemo.org/showthread.php?t=40322 one of the big problems at the
actual Brainstorm process is the lack of working feedback.

So, it would be nice if a developer or Quim Gil itself could mark the selected
solution in the coresponding Brainstorm to this Bug report as Solution and it's
target (PR 1.2 or PR 1.3):
http://maemo.org/community/brainstorm/view/actions_when_device_is_locked_and_a_event_like_aleart-alarm_or_call_happens/

Please continue discussions about this topic here:
http://talk.maemo.org/showthread.php?t=40872 
Use the first link in this post for things about the Brainstorm process itself.
Thankyou.
Comment 54 Andre Klapper maemo.org 2010-04-23 22:02:27 UTC
Fix will be available in next public update (PR1.2) hence setting explicit
Target Milestone.
Comment 55 redex 2010-05-26 17:08:21 UTC
Bug ist not fixed in 10.2010.19-1 (PR1.2)

No changes at the UI when a call is incomming and the device (screen and
keyboard) is locked. Hence not fixed in PR1.2

Is the Target Milestone correct set?
Comment 56 Andre Klapper maemo.org 2010-05-28 01:03:46 UTC
Ah, sorry for being unclear.

What was done for 10.2010.19-1:
1. 0.5 sec delay added between proximity open event and display on action 
   triggered by it.
2. It works for both alarms and calls
Comment 57 ZeeD 2010-05-28 23:53:52 UTC
Super fix!
Nokia rules:))))
HTC Desire is almost in my pocket...
Comment 58 Naba Kumar nokia 2010-05-29 11:25:08 UTC
(In reply to comment #57)
> Super fix!
> Nokia rules:))))
> HTC Desire is almost in my pocket...
> 
But did you check if this solves accidental calls, like on cheeks and pocket?
at least, it hasn't happened with me. If from practical use anyone still gets
it, it would help describing the scenario.
Comment 59 Saturn 2010-05-30 00:30:26 UTC
It has definitely improved - I had only declined accidentally one call in the
last couple of days. Of course it helps that I'm much more careful now.

In my opinion though the situation needs a better solution.
Comment 60 Vijay Venugopal 2010-06-14 14:50:07 UTC
The .05 delay can be called work-around (which doesnt work always) but never a
solution. On top of that the screen has glitches too in portrait mode while
receiving calls. This happens only when the proximity sensor is involved which
makes me suspect the "helpful" 0.5 second workaround is behind it. The solution
is simple and is found in all other nokia touch screens.. 

N900 is the like the watch in spykids with hundreds of features but does not
show time. The phone still is a basic function for the device! But telephony
bugs are not prioritized at all.
Comment 61 Frederik Niedernolte 2010-06-14 15:23:10 UTC
Maybe it is related to bug 10613!?
Comment 62 redex 2010-06-19 11:23:55 UTC
Created an attachment (id=2897) [details]
N900 unlocks the screen itself when receiving a call
Comment 63 redex 2010-06-19 11:28:43 UTC
(In reply to comment #58)
> But did you check if this solves accidental calls, like on cheeks and pocket?

I used the 0.5 delay fix now for 3 weeks. I got 31 calls during this time (I
haven't count my own test calls) 
It's improved. I missed only 6 calls and have 2 accidentally answered during
this time. Before PR1.2 it was more often. (I have no numbers, haven't count it
- just a feeling of improving)
But it is definitively not fixed. I would advice to reopen it.

The proximity sensor was initially developed to lock the keyboard (and now the
touchscreens) during a call while you have the phone on your ear. In this case
it works perfectly. But the misuse to detect the environment if unlocking is a
good idea does not work very well.

> at least, it hasn't happened with me. If from practical use anyone still gets
> it, it would help describing the scenario.

I added a Attachment. I'm lefthanded and I hold my soft bag with the right hand
when pulling the N900 out. As you can see at the image, the proximity sensor
arises first.
My girlfriend owns a Nokia 5800 and had the same problem. Nokia improved it a
little bit with a firmware update by adjusting the proximity sensor parameters
(I guess the same delay). But the real fix for this Bug was on one of the last
Firmware Updates. Now she got Slide to unlock. And the Bug is fixed.
It's very similar to the N97 screen. Here you can find a screenshot:
http://nokiamobileblog.com/wp-content/uploads/2009/06/ccalling-on-n97.jpg

In my opinion not necessary to do the same development steps again and again.
Comment 64 Sivan Greenberg 2010-07-21 15:11:24 UTC
Just to join everybody else on this bug report (it is actually tiring to read
through all the comments but the idea is clear).

For me, mis-using the proximity sensor for that is not a solution and is not
really helping, e.g. the problem as so precisely described here, is *after* you
take the phone from your pocket. If this is a WONTFIX, we need to make
absolutely sure this *properly* addressed possibly the same as in Symbian (the
screenshot here tells it all) for MeeGo, and even then it is a bit un-nice to
tell users who experience this issue to "Upgrade to the next OS, MeeGo" to fix
this, but is better than leaving it as it is and is acceptable for when Maemo
is EOL'd.


(In reply to comment #63)
> (In reply to comment #58)
> > But did you check if this solves accidental calls, like on cheeks and pocket?
> 
> I used the 0.5 delay fix now for 3 weeks. I got 31 calls during this time (I
> haven't count my own test calls) 
> It's improved. I missed only 6 calls and have 2 accidentally answered during
> this time. Before PR1.2 it was more often. (I have no numbers, haven't count it
> - just a feeling of improving)
> But it is definitively not fixed. I would advice to reopen it.
> 
> The proximity sensor was initially developed to lock the keyboard (and now the
> touchscreens) during a call while you have the phone on your ear. In this case
> it works perfectly. But the misuse to detect the environment if unlocking is a
> good idea does not work very well.
> 
> > at least, it hasn't happened with me. If from practical use anyone still gets
> > it, it would help describing the scenario.
> 
> I added a Attachment. I'm lefthanded and I hold my soft bag with the right hand
> when pulling the N900 out. As you can see at the image, the proximity sensor
> arises first.
> My girlfriend owns a Nokia 5800 and had the same problem. Nokia improved it a
> little bit with a firmware update by adjusting the proximity sensor parameters
> (I guess the same delay). But the real fix for this Bug was on one of the last
> Firmware Updates. Now she got Slide to unlock. And the Bug is fixed.
> It's very similar to the N97 screen. Here you can find a screenshot:
> http://nokiamobileblog.com/wp-content/uploads/2009/06/ccalling-on-n97.jpg
> 
> In my opinion not necessary to do the same development steps again and again. 
>
Comment 65 Andre Klapper maemo.org 2010-07-21 15:25:03 UTC
(Please strip unneeded quotes of previous comments and please do not answer
above the quote.)
Comment 66 Naba Kumar nokia 2010-07-22 08:46:15 UTC
Thanks for the feedbacks, and point taken. It's good to hear that the proximity
based delayed fix does help, although it doesn't fix it completed (it wasn't
meant to fix completely). The original idea of changing the UI for handling
unlock was not accepted by UI designers and also deemed not feasible in PR1.2
release time frame, hence this fix was better than nothing. Anyways, I have
brought it to relevant people for further discussion.
Comment 67 redex 2010-09-03 15:24:24 UTC
(In reply to comment #66)
> The original idea of changing the UI for handling
> unlock was not accepted by UI designers and also deemed not feasible in PR1.2
> release time frame, hence this fix was better than nothing. Anyways, I have
> brought it to relevant people for further discussion.

Thanks Naba for taking this. Are there any kind of updates? What happened in
the last 6 weeks?

What was the result of the discussion with the relevant people and what about
reopening this Report?

Thanks for your effort.
Comment 68 Aldo 2010-12-14 06:06:58 UTC
(In reply to comment #67)
> (In reply to comment #66)
> > The original idea of changing the UI for handling
> > unlock was not accepted by UI designers and also deemed not feasible in PR1.2
> > release time frame, hence this fix was better than nothing. Anyways, I have
> > brought it to relevant people for further discussion.
> 
> Thanks Naba for taking this. Are there any kind of updates? What happened in
> the last 6 weeks?
> 
> What was the result of the discusson with the relevant people and what about
> reopening this Report?
> 
> Thanks for your effort.

As I see Nokia doesn't want to fix this, I dunno the reason but I they doesn't
care about the opinion of the customer, saddly other OS are growing meantime "
US designers" let this awsome phone dying. At least these people should explain
why the WONTFIX this. its because they dosen't want yo copy another solutions
(you have a brainstrom of the comunity for that) or because they doesn't want
to admit the awful desing? 

At least you should ponit us how can we change the ui (open source philosophy)
and we let asking this changes.

Regards.
Comment 69 Andre Klapper maemo.org 2010-12-15 18:32:44 UTC
(In reply to comment #68)
> At least these people should explain why the WONTFIX this.

1) This is not a general discussion forum.
2) WONTFIX == Nokia having other priorities.
Comment 70 keuasirin 2011-02-11 08:40:46 UTC
thx