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 log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 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 finger 4. Release stylus or finger EXPECTED OUTCOME: 5. Previously selected text remains selected ACTUAL OUTCOME: 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. REPRODUCIBILITY: Always - also see bug 6016 comment #17 EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: 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.
Should be... REPRODUCIBILITY: Always - also see bug 5033 comment #26
Forwarding Nokia's WONTFIX decision: "Looks like this functionality must not be supported: ****************************** QUOTATION BEGIN ****************************** Cut/Copy/Paste 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 non-editable text. ******************************* 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 spec. 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 up ASAP.
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* Done.
For those compiling themselves: Patch committed at http://gitorious.org/modest/modest/commit/b38bb395947076883ccb68e800b49e8dd68fdc7b
This has been fixed in package modest 3.4.5+0m5 which is part of the internal build version 2010.26-8 (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 update.) 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 http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
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 update version.