maemo.org Bugzilla – Bug 10390
Selection of text is impossible once the email is scrolled
Last modified: 2010-10-25 17:12:35 UTC
You need to
before you can comment on or make changes to this bug.
10.2010.19-1 (reflash not OTA)
EXACT STEPS LEADING TO PROBLEM:
1. Receive a Bugmail email
2. Scroll the email so that two or three new lines of text become visible
3. Attempt to select text from the last visible line using either stylus or
4. Release stylus or finger
5. Previously selected text remains selected
5. The selection changes - it appears to now start with the beginning of the
original selection point (where you started selecting) and ends where you
ended, but 3 or 4 lines further up the screen.
Always - also see bug 6016 comment #17
EXTRA SOFTWARE INSTALLED:
In addition, selecting text at the bottom of the email is simply impossible.
Take a typical bugmail email, scroll to the bottom and try to select the two
words "Configure bugmail:" - without even lifting the stylus the selection
point within the email has changed and jumped randomly further up the email.
Always - also see bug 5033 comment #26
Forwarding Nokia's WONTFIX decision:
"Looks like this functionality must not be supported:
****************************** QUOTATION BEGIN ******************************
Following Hildon 2.2 UI Style, there are no application UI commands for Cut,
Copy or Paste. Instead, this functionality is ONLY provided via HW key
shortcuts (CTRL-X, CTRL-C, CTRL-V) and via virtual keyboard (VKB) menu.
Since Hildon 2.2 UI Style does not have initial focus or non-editable text
"paint" selection, this means the cut/copy/paste functionality is ONLY
supported for Text Entry and Text Area widgets. It is NOT possible to copy
******************************* QUOTATION END *******************************
Currently, the user can select text via:
1) HW key shortcuts (CTRL-X, CTRL-C, CTRL-V);
2) Virtual keyboard (VKB) menu;
So, the current implementation corresponds to the current UI specification.
Please, note, that other applications (e.g. Web app) implement this
functionality in the same way it is specified in the UI spec."
Well, it *is* possible to copy the text from the email even though it is
non-editable (see bug 5033 which made this possible) - it's just that the
selection to be copied goes haywire when the stylus or finger is lifted.
It's this latter issue, the selection area going haywire, that is the problem
not that that text cannot be copied. Once the text to be copied is selected, it
can be copied using CTRL-C however when the stylus/finger is lifted from the
screen in order to enter CTRL-C on the keyboard the selection area
automatically changes which prevents the user from copying the text they would
like to copy.
It seems that the developer has not understood the problem, has not reproduced
it (did they even try?) and has once again blown off a bug by spouting from the
Not good, Andre.
Please reopen, and to expedite matters I suggest the developer communicate
directly, *here*, so that any remaining confusion on their part can be cleared
I should add, the selection only goes haywire when the stylus/finger is lifted
after the email has been scrolled (perhaps some internal position/tracking is
not taking account of the scroll position?)
Selecting and copying works perfectly when the email has NOT been scrolled -
it's likely this was the only use-case to have been tested before signing off
on this new functionality (introduced by bug 5033 in PR1.2).
The quote in comment #2 is completely and utterly irrelevant to this bug.
Reopening, let's try again Andre. :)
(In reply to comment #3)
> Please reopen, and to expedite matters I suggest the developer communicate
> directly, *here*
For those compiling themselves: Patch committed at
This has been fixed in package
which is part of the internal build version
(Note: 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
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
The problem reported here should be fixed in the update that was released today
for public: The Maemo5 update version 20.2010.36-2 (also called "PR1.3"
sometimes). Please leave a comment if the problem is not fixed for you in this