The default bug view has changed. See this FAQ.

Control shift right arrow selects way too much, even invisibly selecting following blank lines and into following <div> elements

NEW
Unassigned

Status

()

Core
Selection
a year ago
a year ago

People

(Reporter: dbowser, Unassigned)

Tracking

({regressionwindow-wanted})

Trunk
All
Windows
regressionwindow-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Steps to reproduce:

Write a sentence ending in punctuation that is followed by a blank line and then the signature. Move the cursor to the middle of the line and use shift right arrow to try to select the words to the right up until the punctuation to replace the end of the sentence.


Actual results:

The last word AND punctuation are highlighted and the cursor is left on that line. However, if you delete or type something else, everything up to the signature (including the empty line and the line break after it) is deleted moving the signature to the end of your sentence.


Expected results:

Shift right arrow should only select one word at a time even if it is the last word in the sentence. It should not include the line break after that word unless you hit it again and it certainly should not go to the next word. Line breaks should be considered another word as should punctuation. Look at how Word handles it which is the same a many other editors, all that I have used for MANY years :D (Yea, I am that old)

Comment 1

a year ago
You mean: <Ctrl> <shift> <right-arrow>. Just <shift> <right-arrow> selects one character at a time.

I can see that <Ctrl> <shift> <right-arrow> selects way too much and deleting or overwriting does a lot of damage.

As most people don't know, Thunderbird uses Mozilla Firefox technology under the covers. So this is not a Thunderbird bug but a Mozilla core bug. Let me attach a simple web page which will show you what I mean.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Shift right arrow messes up on last word in a line when composing message → Control shift right arrow selects way too much, even invisibly selecting following blank lines and into following <div> elements

Updated

a year ago
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk

Updated

a year ago
Component: Message Compose Window → Editor
Product: Thunderbird → Core

Comment 2

a year ago
Created attachment 8731909 [details]
Web page showing the bug.

Click behind the | on the second line and press <ctrl><shift><right-arrow> to select the word. Press delete or any letter of your choice. Result: Terrible.

(Chrome does a better job.)
(Reporter)

Comment 3

a year ago
Yes! Sorry for not getting it clear and thanks for all the added information.

This has been one of the major issues I have had with Thunderbird for quite a while. I end up having issues with it quite frequently so have been surprised that it hasn't been addressed. Hopefully now it will be :)

Comment 4

a year ago
(In reply to dbowser from comment #3)
> Hopefully now it will be :)
I have bad news for you. Mozilla core software is organised into modules:
https://wiki.mozilla.org/Modules/Core
The modules which are responsible for this are Core::Editor and Core::Selection. These modules are unowned and there is little chance to get anything fixed. I've alert Mozilla's CEO to this fact and so far nothing has happened:
https://groups.google.com/d/msg/mozilla.governance/-0sAFE-_Us4/8zvhqcrRCAAJ
I've joined the Thunderbird team one year ago to fix bugs, especially in Core::Editor, but since I didn't even know until today that <ctrl><shift><right-arrow> existed, it's not on my to-do list. Sorry.

One day perhaps Thunderbird will have a different financial home and users might be able to influence development, but not so far.

Actually, why don't you use <shift><end> to select to the end of the line, that works better.
(Reporter)

Comment 5

a year ago
Ah, OK. Good to know at least. A related issue is trying to add a space after an emoticon. I guess that won't be fixed either. Oh well. Still prefer it to Outlook.
It works fine for me in a Firefox Nightly on Linux64, fwiw.

Can you try to figure out a regression range please?
Keywords: regressionwindow-wanted

Comment 7

a year ago
(In reply to dbowser from comment #5)
> Ah, OK. Good to know at least. A related issue is trying to add a space
> after an emoticon. I guess that won't be fixed either. Oh well. Still prefer
> it to Outlook.
Off topic: As far as I know that's fixed, bug 182941, to be released in TB 45.

Comment 8

a year ago
(In reply to Mats Palmgren (:mats) from comment #6)
> It works fine for me in a Firefox Nightly on Linux64, fwiw.
Thanks for checking this. This works fine for me too with FF 45 on a Linux Mint (64bit) system (unbelievable).

> Can you try to figure out a regression range please?
Are you sure this is a regression? Some editor/selection bugs have been there since the days of Netscape. I don't have any other version of FF installed, but let's ask the resident regression range expert.

Hi Alice0775, can you check with the given attachment 8731909 [details] how long this bug has existed on Windows. I don't think a regression window would be all that useful if it wasn't working before - say - FF 12. Or maybe it would.

Note: I moved this to Core::Selection, but it might turn out that this is a Core::Widget:Win32 problem.
Component: Editor → Selection
Flags: needinfo?(alice0775)
OS: All → Windows

Comment 9

a year ago
Works 15-Oct-2008 nightly
Broken: 16-Oct-2008 nightly
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea37481b6803&tochange=eb503e103377

Suspect: Bug 157546
Flags: needinfo?(alice0775)

Comment 10

a year ago
Thanks Alice, I've never understood how you can do it so quickly. Amazing!
Bug 157546 landed https://hg.mozilla.org/mozilla-central/rev/34967ab14be8 right into the middle of /editor and /layout. I'm don't understand why the behaviour would be different on Windows and Linux though.
You need to log in before you can comment on or make changes to this bug.