maemo.org Bugzilla – Bug 10353
result of USSD query should not be shown to user at all (If he wishes that)
Last modified: 2010-11-21 17:37:10 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
1. Make USSD query not from phone application (through pnatd, ussdquery.py from
ussd-common or via ussd-widget)
2. Application, which made a query should receive an answer. User shouldn't:
application would do it implicitly if needed.
A popup appears with reply. I don't want to see this box every 2 hours when
ussd-widget renews balance, if I would like to see the reply, I would look at
EXTRA SOFTWARE INSTALLED:
IMHO, such box should be shown only if application, which started the query,
wants to. Or at least I need a way to disable this box, how this could be done?
I use AT commands to make USSD queries and there seems, that there is no
documentation, how this can be done in another way.
User-Agent: Opera/9.80 (X11; Linux x86_64; U; ru) Presto/2.2.15
(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.
(In reply to comment #3)
> > (not a blocker)
> Depends on the view.
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.
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
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.
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
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.
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.
(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
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
> 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
(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!
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
I would understand if this bug would be hard to fix, but it is not.
Management decided it wasn't important enough.
Complaints can be directed via Nokia Customer Care.
Dear Andre, unfortunatelly i have to reopen this bug.
The bug is still in PR 1.3. And I have told why it is a bug many times
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
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.
(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).
MeeGo bug: http://bugs.meego.com/show_bug.cgi?id=10271
(Thanks for filing it!)