Open Bug 46784 Opened 24 years ago Updated 4 years ago

Selection of blank lines invisible in textarea

Categories

(Core :: DOM: Selection, defect, P5)

defect

Tracking

()

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.
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
reassigning
Assignee: rods → beppe
setting to future
Keywords: helpwanted
Target Milestone: --- → Future
Status: NEW → ASSIGNED
Updating QA contact.
QA Contact: ckritzer → bsharma
*** Bug 66136 has been marked as a duplicate of this bug. ***
QA Contact Update
QA Contact: bsharma → vladimire
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 → ---
setting back to future
Target Milestone: --- → Future
-->kin
Assignee: beppe → kin
Status: ASSIGNED → NEW
Assignee: kinmoz → nobody
Component: Layout: Form Controls → Selection
QA Contact: vladimire → selection
Also would definitely like to see this solved, if possible. Agree with Matthew that Mac OS / WebKit / Google Chrome approach is good.
Although tiny thing, this really annoys me... Nice to know there are people on it! Thanks!

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.