46784 - Selection of blank lines invisible in textarea

Status: NEW

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

Description

[[e-mail]]

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

[Gervase Markham [:gerv]]

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

Comment 2

[rods (gone)]

reassigning

Comment 3

[rubydoo123]

setting to future

Comment 4

[bsharma]

Updating QA contact.

Comment 5

[Kathleen :Brade]

*** Bug 66136 has been marked as a duplicate of this bug. ***

Comment 6

[Vladimir Ermakov]

QA Contact Update

Comment 7

[Matthew T (active 1999-2002)]

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]

Comment 8

[rubydoo123]

setting back to future

Comment 9

[Kathleen :Brade]

-->kin

Comment 13

[Edmar]

Also would definitely like to see this solved, if possible. Agree with Matthew that Mac OS / WebKit / Google Chrome approach is good.

Comment 14

[Bruno Braga]

Although tiny thing, this really annoys me... Nice to know there are people on it! 

Thanks!

Comment 15

[Jens Stutte [:jstutte]]

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.