175260 - misbehaviour in text inputs / selection / mouse clicks

Status: RESOLVED INVALID

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

Description

[Markus Bertheau]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020909
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020909

1. Have at least two <input type="text">s on the page
2. Type something in the first text field.
3. Select something in the first text field (with the mouse), including the last
character in the text field in the selection
4. Focus (with the mouse) the other text field.
(Here the selection in the first text field disappears)
5. left click and hold in the first text field
  Actual results:
    While the mouse button is down, the text that was selected previously is
shown selected.
  Expected results:
    No text is selected.

Ann: This only works if you include the last character in the initial selection.

This is very inconvenient for copy and paste operations.


Reproducible: Always

Steps to Reproduce:

Comment 1

[José Jeria]

Can you attach a testcase?

Comment 2

[Markus Bertheau]

Attachment: testcase.html

Validates against XHTML-Strict, rendered in standards compliance mode

Comment 3

[Boris Zbarsky [:bzbarsky]]

Confirming.  We probably clear the selection onfocus, which is not till after
you release...  We should clear it onblur, perhaps....

Comment 4

[Markus Bertheau]

That wouldn't explain why the selection only happens if you include the last
character in the initial selection, would it?

Comment 5

[John Keiser (jkeiser)]

The selection happens for me no matter which characters you select.  It is
arguable that this is a feature, so that you can drag the selection.  What bad
behavior does it create for copy and paste?  (i.e. what can you not do that you
want to do?)

Comment 6

[Markus Bertheau]

It destroys the content of my clipboard.

Comment 7

[John Keiser (jkeiser)]

Oh, on Linux?  OK.

Comment 8

[Joe Francis]

Not really editor core.  Brade, do you know who owns this?

Comment 9

[Kathleen :Brade]

Akkana--can you look over this bug and explain to me the issue for linux?
Possibly this is a duplicate selection bug?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hm... I can reproduce the _visual_ misdrawing of the selection, but the PRIMARY
contents are unaffected by it...

Comment 11

[Akkana Peck]

My PRIMARY isn't overwritten either, so the only problem I see is that it's
visually weird ("what's that doing there?  Oh, now it's gone").

Making it clear selection on focus would destroy the ability to drag the
selection.  That would be a big win as far as I'm concerned (I'm always getting
screwed up by accidental drags when I just wanted to change an existing
selection, and the drag isn't a normal behavior in text fields in any other unix
app) but I suppose there may be people who like the current behavior (mac-linux
switchers?), so perhaps it should be configurable.

Comment 12

[Tuukka Tolvanen (sp3000)]

re comment 4, you do have to include the last character in the selection if you
want to reproduce the bug by clicking on the empty right hand side part of the
textfield; otherwise hitting the invisible selection is sufficient. If you miss
the selection, it is cleared (as in: doesn't appear on mousedown).

re comment 5, I don't see why anyone would want to drag an invisible old
selection that only appears on mousedown...?

re comment 6, the old selection getting rendered doesn't clobber my PRIMARY
either. (linux moz 1.3a, phoenix 20021218)

re comment 3, clearing selection onblur (if it doesn't imply clearing PRIMARY)
would seem reasonable, unless there's some benefit in simultaneously retaining a
discrete selection for each textbox. I don't see how those could be used anyway
since 
  - keeping it for the drag feature isn't useful as the selection isn't visible
until mousedown on it;
  - there's no way of focusing the textbox without losing the selection in it
that I know of (clicking in clears, tabbing in selects all)?
Onfocus happens on mousedown for my textbox here? Or maybe I'm missing something
in which case n/m...

Comment 13

[Kathleen :Brade]

Can someone clarify what the bug is?  What needs to be fixed?

At this point, my understanding is that copy/paste are unaffected (as opposed to
what the original comment describes)

Comment 14

[Kathleen :Brade]

resolving as invalid since I have gotten no clarification and others don't see
any problems with primary clipboard