Bug 10353 - (int-171346) result of USSD query should not be shown to user at all (If he wishes that)
(int-171346)
: result of USSD query should not be shown to user at all (If he wishes that)
Status: RESOLVED WONTFIX
Product: Chat & Call & SMS
Call Application UI
: 5.0:(10.2010.19-1)
: All Maemo
: Unspecified major with 12 votes (vote)
: ---
Assigned To: rtcomm@maemo.org
: call-ui-bugs
: http://bugs.meego.com/show_bug.cgi?id...
:
:
:
  Show dependency tree
 
Reported: 2010-05-27 17:10 UTC by Alexey Guseynov
Modified: 2010-11-21 17:37 UTC (History)
3 users (show)

See Also:


Attachments


Note

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


Description Alexey Guseynov (reporter) 2010-05-27 17:10:59 UTC
SOFTWARE VERSION:
10.2010.19-1

EXACT STEPS LEADING TO PROBLEM: 
1. Make USSD query not from phone application (through pnatd, ussdquery.py from
ussd-common or via ussd-widget)

EXPECTED OUTCOME:
2. Application, which made a query should receive an answer. User shouldn't:
application would do it implicitly if needed.

ACTUAL OUTCOME:
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
the desktop.

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
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
Version/10.10
Comment 1 Andre Klapper maemo.org 2010-05-27 19:10:09 UTC
(not a blocker)
Comment 2 Andrei Dancau 2010-05-27 19:15:18 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Nikita Youshchenko 2010-05-28 09:44:20 UTC
(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.
Comment 4 Alexey Guseynov (reporter) 2010-05-28 11:22:53 UTC
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 maemo.org 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 maemo.org 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."
Comment 7 Alexey Guseynov (reporter) 2010-05-29 15:01:48 UTC
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.
Comment 8 Nikita Youshchenko 2010-05-30 20:15:57 UTC
> 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?
Comment 9 Alexey Guseynov (reporter) 2010-05-30 20:30:34 UTC
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.
Comment 10 Alexey Guseynov (reporter) 2010-06-10 22:04:13 UTC
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 maemo.org 2010-06-10 22:14:31 UTC
Please do not reopen WONTFIX bugs without providing reasons.
Comment 12 Nikita Youshchenko 2010-06-10 22:23:38 UTC
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 maemo.org 2010-06-10 22:37:42 UTC
(In reply to comment #12)
> Reason has been provided. Go read bug log.

Exactly: See comment 6.
Comment 14 Nikita Youshchenko 2010-06-10 22:48:45 UTC
(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.
Comment 15 Alexey Guseynov (reporter) 2010-06-10 22:49:48 UTC
(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 maemo.org 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 maemo.org 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.)
Comment 18 Alexey Guseynov (reporter) 2010-10-26 22:20:44 UTC
> 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 maemo.org 2010-10-26 23:29:11 UTC
Management decided it wasn't important enough.
Complaints can be directed via Nokia Customer Care.
Comment 20 Alexey Guseynov (reporter) 2010-11-16 09:11:18 UTC
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 maemo.org 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 maemo.org 2010-11-21 17:37:10 UTC
MeeGo bug: http://bugs.meego.com/show_bug.cgi?id=10271
(Thanks for filing it!)