Closed
Bug 28313
Opened 25 years ago
Closed 25 years ago
Shift+Ctrl+Arrow doesn't extend/create selection in textarea
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: bunkin, Assigned: Brade)
References
()
Details
On the _URL_ type any text into one of the multiline textarea fields, then try
to select some text pressing Shift+Ctrl+Right or +Left. For me it doesn't make a
selection. It may be because of page's charset (windows-1251).
I'm using build 021708 on Windows 98 SE.
Comment 2•25 years ago
|
||
Confirmed with 2000-02-17-08-M14 nightly binary on Windows NT:
Shift+Ctrl+Arrow indeed doesn't extend/create selection in <TEXTAREA>
- this can be checked on any bugzilla show_bug.cgi page.
This looks like much the same problem that had been afflicting <INPUT> fields
reported as bug 25462, "Control shift left arrow doesn't select word",
VERIFIED FIXED (and rechecked now, working properly for <INPUT>).
I'd call this a "Selection" bug, and it is definitely a regression since
bug 25462 was filed - I checked <TEXTAREA> as well as <INPUT> then.
Assignee | ||
Comment 4•25 years ago
|
||
I'm confused about this bug. What is the expectation when you press control-
shift-arrow? My guess is that this should extend or reduce the selection by one
word. I believe that is how 4.x works on Windows. Can someone confirm that?
Also, did the word-selection actually work in prior versions of 5.0?
Reassign to myself
Assignee: mjudge → brade
Component: HTML Form Controls → Editor
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15
Assignee | ||
Comment 5•25 years ago
|
||
removing regression keyword since it's not clear this is a regression.
Assuming bug is for word selection left/right functionality; accepting
Status: NEW → ASSIGNED
Keywords: regression
Comment 6•25 years ago
|
||
Since you asked for clarification: behaviour in Windows native apps is identical
(as far as I saw) to Mozilla from the point of view of cursor movement, Mozilla
just needs to extend the selection appropriately.
I thought it might help to have a test case giving the expected results:
text: sam is testing this word
cursor begins after the "s" in testing
shift-ctrl-left: selection "tes"
shift-ctrl-left again: selection "is tes"
shift-ctrl-right: selection "tes"
shift-ctrl-right again: selection "ting "
shift-ctrl right again: selection "ting this "
If, after making that selection you cancel it by moving either left or right,
the cursor should end up one place to the left or right of the current
"extension" (e.g. if you cancel by pressing left at the end there, the cursor
should end up after the "s" in this; if you cancel by pressing right, it ends up
after the "w" in word) - so that's something to check too.
hope this is useful, apologies if not
Assignee | ||
Comment 7•25 years ago
|
||
This should be tested on all platforms; the wrong command was being executed in
textareas.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
OS: Windows 98 → All
Hardware: PC → All
Resolution: --- → FIXED
Comment 8•24 years ago
|
||
using the build from 10/29 on win95 -- the shift+ctrl+arrow selects a word at a
time, each time I select the arrow key it does what I expect it to.
I did not test this on mac or linux, someone else will have to check those.
Comment 9•24 years ago
|
||
Seems to select a word at a time on linux branch builds, too.
Comment 10•24 years ago
|
||
verified on Mac 10/31 build. thus all platforms are tested..
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•