Open
Bug 46784
Opened 24 years ago
Updated 4 years ago
Selection of blank lines invisible in textarea
Categories
(Core :: DOM: Selection, defect, P5)
Core
DOM: Selection
Tracking
()
NEW
Future
People
(Reporter: neil, Unassigned)
References
Details
(Keywords: helpwanted)
BuildID: 2000072708
Selected blank lines are visible in Composer because of a funny (to me) blue bar
to the left of the line. However there is no indication that a blank line is
selected in a textarea.
Reproducible: Always
Steps to Reproduce:
1. Open a Composer window
2. Insert blank lines
3. Select some of the lines
4. Find a textarea (e.g. the bug report comments)
5. Insert blank lines
6. Select some of the lines
Actual Results: No caret or selection visible
Expected Results: Some sort of indication that there is a selection, or at
least that the caret has moved.
When a line ending is selected, Excel and Foxpro paint the entire line in the
selected colour while Word and WordPad paint an extra block at the end of the line.
A Communicator textarea uses the standard Windows edit control which doesn't
show the selection or hide the caret. In a Composer window Communicator paints
an extra block whereas Mozilla paints a blue line but only for blank lines.
Comment 1•24 years ago
|
||
Given that the Communicator 4.x (and, indeed, Windows) behaviour is not to show
indication of selected blank lines in a textarea, this is an RFE for XP Widgets.
Gerv
Severity: trivial → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 7•23 years ago
|
||
It's a bug, Jim. Standard behavior on Mac OS is for the whole of a selected line
to be highlighted, no matter how many characters are in it. This is useful
because it helps distinguish between fully and partly selected lines. Since
(according to Neil) Windows is inconsistent in this regard, perhaps we could
just implement the Mac OS behavior ... :-)
[Unsetting target milestone due to change in severity]
URL: #
Severity: enhancement → minor
OS: Windows 95 → All
Hardware: PC → All
Target Milestone: Future → ---
Updated•17 years ago
|
Assignee: kinmoz → nobody
Component: Layout: Form Controls → Selection
QA Contact: vladimire → selection
Comment 13•14 years ago
|
||
Also would definitely like to see this solved, if possible. Agree with Matthew that Mac OS / WebKit / Google Chrome approach is good.
Comment 14•14 years ago
|
||
Although tiny thing, this really annoys me... Nice to know there are people on it!
Thanks!
Comment 15•4 years ago
|
||
Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Severity: minor → S4
Priority: P3 → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•