One possible solution to this problem is to have a on-screen slide instead of
the answer and reject buttons.

Would be helpful, yes.

I have rejected about half the calls I receive. This really is a problem for
me.

Comment 3 Andre Klapper 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 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 2009-12-04 01:29:50 UTC

*** Bug 6552 has been marked as a duplicate of this bug. ***

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 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.

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 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.

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 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 2009-12-22 16:20:45 UTC

*** Bug 7218 has been marked as a duplicate of this bug. ***

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...

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 2009-12-28 14:13:57 UTC

As written before, Nokia has decided that this is WONTFIX. Hence closing again.

Please vote for this bug, maybe nokia will look at it again.

Comment 17 Andre Klapper 2010-01-04 00:19:35 UTC

*** Bug 7602 has been marked as a duplicate of this bug. ***

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

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.

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.

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. :)

Slide to the left -> Accept call
Slide to the right -> Deny call

Simple as that and much safer (also looks fancy)

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.

(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 !!

flinkeKoralle described the issue perfectly. This should be addressed ASAP
because it is annoying as hell.

Comment 26 Andre Klapper 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.

Here is a brainstorm link for voting:
http://maemo.org/community/brainstorm/view/change_ui_for_incoming_call_in_portrait_mode-split_answer_and_reject_buttons

Link for discussion:
http://talk.maemo.org/showthread.php?t=41411

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

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.

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 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.

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 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 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 2010-01-25 15:54:42 UTC

re-assign to default assignee.

(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!

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.

(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.

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 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.

>> 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 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.

(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 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).

(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 2010-02-02 13:50:59 UTC

*** Bug 8769 has been marked as a duplicate of this bug. ***

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.

"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 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 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/

Thanks for fixing.
How is it fixed and will it be included in the PR 1.2 firmware release?

Comment 52 Andre Klapper 2010-03-30 13:55:57 UTC

All we know is written in comment 50. That's it.

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 2010-04-23 22:02:27 UTC

Fix will be available in next public update (PR1.2) hence setting explicit
Target Milestone.

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 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

Super fix!
Nokia rules:))))
HTC Desire is almost in my pocket...

Comment 58 Naba Kumar 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.

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.

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.

Maybe it is related to bug 10613!?

Created an attachment (id=2897) [details]
N900 unlocks the screen itself when receiving a call

(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.

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 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 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.

(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.

(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 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.

thx

Are there any updates on this? Can i adjust the behaviour somehow so it won't
unlock and drop the call while being still in my pocket?