maemo.org Bugzilla – Bug 6857
USSD codes are not recognized in chat
Last modified: 2010-03-15 20:52:09 UTC
You need to
before you can comment on or make changes to this bug.
Maemo 5, 1.2009.41-10
EXACT STEPS LEADING TO PROBLEM:
Receive a message referring to a USSD code (*123*45# like), mostly in automated
messages from operators. Click/save code.
Initiate request or add to contacts
Only a fragment of the code is detected/highlighted. A USSD code of *121*2#
appears as '121'
EXTRA SOFTWARE INSTALLED:
This is obviously linked to https://bugs.maemo.org/show_bug.cgi?id=5357 but
since it is already assigned, it would be nice to handle this problem in
conjunction with that.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124pre)
Gecko/20090916 Ubuntu/8.04 (hardy) Shiretoko/3.5.4pre
Bug filed in internal bugzilla
Also, please update to 1.2009.42-11.
1.2009.41-10 is outdated.
(I don't work on this product, but I'm curious.)
I'm assuming that USSDs can be dangerous and that users are unlikely to
understand what they do. (please correct me if i'm wrong)
Do you expect these to work from a google chat / skype chat, or only from an
sms view? if only from an sms view, should they work from any sender or only
senders w/ 4/5 digit numbers?
As for dangerous, IMO it as dangerous as any other 'regular' number, as those
can harbor high fee or automated services, too. A confirmation of "This is a
supplementary service call number. Are you sure ?" or sorts would be IMHO
enough of a warning, but I guess it's more of a policy question.
Skype/XMPP is an interesting angle - those are not related to your cellular
provider, so it makes far less sense to parse them there (who would send you
USSD codes ? friends ?), so, apart from the reason of consistency, it makes
sense to draw a line there (however, I would suggest ignoring the whole code in
that case, not treat it as partial numbers as now).
I don't have enough info to say whether 4/5 sender is a good filtration or not
(i.e. Can it be forged ? Are there providers who define a longer (or missing)
This has been fixed in package
which is part of the internal build version
(Note: 2009/2010 is the year, and the number after is the week.)
*#1234# and +440000000000*56 are properly highlighted.
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
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
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).
Sorry for the bugmail noise (you can filter on this message).