Comment 1 Andre Klapper 2010-05-27 19:10:09 UTC

(not a blocker)

*** This bug has been confirmed by popular vote. ***

(In reply to comment #1)
> (not a blocker)

Depends on the view.
IMO, ussd-widget is one of the "killer features" of n900. And breaking it is a
huge anti-user step.

Modal dialog, which appears every 2 hours is annoying. Every time I switch on
the phone i have to click on "Ready" button. It is not good when you are doing
something, especially playing, and in the moment, when you need to make some
action, dialog appears.

Comment 5 Andre Klapper 2010-05-28 16:04:48 UTC

(In reply to comment #3)
> > (not a blocker)
> Depends on the view.

No. https://bugs.maemo.org/page.cgi?id=fields.html#bug_severity

Comment 6 Andre Klapper 2010-05-29 14:42:12 UTC

Internal WONTFIX comment by Nokia:
"Yes, we are aware of the somewhat redundant dialog in this case and already
discussed whether it could be suppressed.

The conclusion was we leave it as is. The reason is firstly that we are
required to handle mobile-terminated (i.e. network-originated) USSD sessions,
and there's (at least now) no way for the UI to distinguish a session initiated
by ussdquery.py from a session initiated by the network. Secondly, the call UI
is by design shadowing modem signaling, and just like "ATD555;" would make the
in-call UI appear, in the case discussed here, the result dialog appears.

Thus resolving as WONTFIX."

Then may be there should be a way for an application to tell, that it is
waiting for a USSD session and would take care of the next arriving message?
Theoretically there is a chance, that at the same moment network-originated
message would arrive and application would receive it. But as far as I don't
remember my phone ever receiving network-originated messages, this situation
should newer occur.
And it shouldn't result in something serious, because user would receive both
messages, but via different applications.

> The conclusion was we leave it as is. The reason is firstly that we are
> required to handle mobile-terminated (i.e. network-originated) USSD sessions,
> and there's (at least now) no way for the UI to distinguish a session
> initiated by ussdquery.py from a session initiated by the network.

Crap.

N900 was out there for months without any support for ussd at all. Why
network-initiated messages received by Nokia users during all that time are not
important for Nokia, while almost-zero-probable loose of message caused by race
between ussdquery.py and network matter.

I'm afraid that real reason is that Nokia does not care of it's users at all.

> Secondly, the call UI
> is by design shadowing modem signaling, and just like "ATD555;" would make the
> in-call UI appear, in the case discussed here, the result dialog appears.

Broken design must be fixed. Especially in cases like this one where a fix
could be trivial.

> Thus resolving as WONTFIX.

WONTFIX is not a proper resolution for serious functionality loss.

Bugzilla does not allow me to reopen the bug - Alexey (reporter), could you
please do?

I won't reopen this bug, instead I'll make my own ussd implementation, with
blackjack and hookers. I've already made hacked librtcomm which doesn't display
dialogs, when ussd replies are received. Now it is needed to make ussd-pad
usable and make packages.
I think I'll have time for this next week.

First version of USSD4all is ready. It fixes this problem.
http://kibergus.su/node/41

But now a bigger problem arises. What would be when you suddenly decide to
update your librtcom-call-ui? Current realization of hack in USSD4all won't be
able to patch it and this bug would pop up again and again. Every time user
would get problems and every time they will have to wait until new hack would
be done.
I hope, that it is possible to find some solution. If you think, that it is not
possible implement scheme, introduced in USSD4all, than may be you could
provide reliable way to disable these pop-ups from librtcom-call-ui? Then this
two implementations could coexist without ugly fixes.

Comment 11 Andre Klapper 2010-06-10 22:14:31 UTC

Please do not reopen WONTFIX bugs without providing reasons.

Reason has been provided. Go read bug log.

2Alexey: you may make your package Depend: on particular version of
librtcom-call-ui, thus blocking update of that package. Also, it may be a
better idea not to patch binary, but instead dpkg-devert file in question, and
provide your own version.

Comment 13 Andre Klapper 2010-06-10 22:37:42 UTC

(In reply to comment #12)
> Reason has been provided. Go read bug log.

Exactly: See comment 6.

(In reply to comment #13)
> (In reply to comment #12)
> > Reason has been provided. Go read bug log.
> 
> Exactly: See comment 6.
> 

See comment 8 for a reply.
This bug is about PR1.2 introduces serious functionality loss.
WONTFIX reply to it means that you don't care.

(In reply to comment #11)
> Please do not reopen WONTFIX bugs without providing reasons.
> 

This bug was closed because your programmers decided, that it is not possible
to fix it. I think, that I've fixed it. And this is a good reason to talk about
possibility to fix it again. 
No problem, I'll provide reason:

>Internal WONTFIX comment by Nokia:
>"Yes, we are aware of the somewhat redundant dialog in this case and already
>discussed whether it could be suppressed.
>
>The conclusion was we leave it as is. The reason is firstly that we are
>required to handle mobile-terminated (i.e. network-originated) USSD sessions,
>and there's (at least now) no way for the UI to distinguish a session initiated
>by ussdquery.py from a session initiated by the network.

Now it is possible to distinguish network-originated USSD sessions from
sessions initiated by ussdquery.py. Right before making a query ussdquery.py
makes DBus method call to su.kibergus.ussdd.skip_next(). This means, that there
is some application capable to handle incoming reply, so next received reply
should not be shown to user. If application doesn't want to wait any more it
ends su.kibergus.ussdd.show_next(). Proper locking guaranties, that if queries
are done only through ussdquery.py this scheme always works.
The only problem is theoretically possible race condition when
network-originated USSD session comes at the same moment when ussdquery.py
wants start it's own session because I can acquire lock only when incoming
session already received.
There are two possible solutions:
1) Leave this race condition. network originated sessions are rare and chance
to hit this situation is very small. So not handling it properly is a less
evil, than showing every incoming message. I emphasize, that as soon as ussdd
(daemon from USSD4all) is notified about network originated session through
DBus it acquires lock, so race condition can happen only in interval several
seconds long. 
2) Implement locking in modem software. Before sending a query application
should acquire lock from modem and modem should reject all network originated
sessions until lock is released. This solution is better if it is possible to
implement it.

> Secondly, the call UI
>is by design shadowing modem signaling, and just like "ATD555;" would make the
>in-call UI appear, in the case discussed here, the result dialog appears.

I don't see a problem here. Call UI should work through ussdquery.py or through
similar service. May be such service should be implemented inside call UI.
Actually, I hoped, that with PR 1.2 I wouldn't need ussdquery.py and would be
able to use DBus interfaces as it is done for other n900 functions.

If you install USSD4all you would find out, that call UI still works. That's
because sessions initiated by it are just handled as network originated ones.
If we would have proper locking as described above, no changes would be needed
at all.

Comment 16 Andre Klapper 2010-06-10 23:41:16 UTC

(In reply to comment #15)
> This bug was closed because your programmers decided

Just to clarify: It's neither "your" nor "programmers" because I'm not a Nokia
employee and because it's Nokia's *management*.

> No problem, I'll provide reason:

Thanks a lot, that comment explained things much better!

Comment 17 Andre Klapper 2010-10-26 19:59:44 UTC

Still it's a WONTFIX according to Nokia.
Changing status here to reflect this.

(Note that the Maemo 5 platform components are considered stable by Nokia.
Only major issues have a chance of being addressed by Nokia.
MeeGo Handset is where the unstable development is taking place. If you are a
developer (not a "normal" end-user) feedback about MeeGo Handset User Interface
issues is specially welcome, e.g. via the MeeGo bugtracker at
https://bugs.meego.com. Please note that MeeGo for the Nokia N900 is unstable.)

> Only major issues have a chance of being addressed by Nokia.
This is a major bug.
I insist, that stable software must not require end user to disassemble it and
change binaries in hex editor.
I'm also frustrated, that I have to do it again and I don't have much time for
it.

I would understand if this bug would be hard to fix, but it is not.

Comment 19 Andre Klapper 2010-10-26 23:29:11 UTC

Management decided it wasn't important enough.
Complaints can be directed via Nokia Customer Care.

Dear Andre, unfortunatelly i have to reopen this bug.
Pros:
    The bug is still in PR 1.3. And I have told why it is a bug many times
here.
Cons:
    Any? So far nokia has only answered by a polite form of "fuck off" ether
through you or through customer service. I hope you would agree, that "fuck
off" is not an answer for a question "Why this bug can't/should not be fixed?"
or "Why it is hard to fix it?"
Isn't it just polite (this is adressed to nokia, not to you) to tell why you
have to do something bad if you have? So plese give a reason before for closing
the bug.

I also haven't seen any statements like "We are unable to fix it for maemo but
we would not do the same mistakes in future versions." or just "Fixed for next
OS version for next device." which I have seen in other bugs.

Comment 21 Andre Klapper 2010-11-18 22:36:06 UTC

(In reply to comment #20)
> Dear Andre, unfortunatelly i have to reopen this bug.

Please don't reopen a WONTFIX as a sign of protest.

And as much as I personally agree with your opinion, the place to express valid
criticism on Nokia's behaviour is by contacting Nokia Customer Care (or ranting
in forums, blogs etc if you feel like).

Comment 22 Andre Klapper 2010-11-21 17:37:10 UTC

MeeGo bug: http://bugs.meego.com/show_bug.cgi?id=10271
(Thanks for filing it!)