misbehaviour in text inputs / selection / mouse clicks




16 years ago
16 years ago


(Reporter: markus, Assigned: Brade)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
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

16 years ago
Can you attach a testcase?

Comment 2

16 years ago
Created attachment 103313 [details]

Validates against XHTML-Strict, rendered in standards compliance mode
Confirming.  We probably clear the selection onfocus, which is not till after
you release...  We should clear it onblur, perhaps....
Ever confirmed: true

Comment 4

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

Comment 5

16 years ago
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?)
Assignee: jkeiser → jfrancis
Component: Layout: Form Controls → Editor: Core
QA Contact: tpreston → sujay

Comment 6

16 years ago
It destroys the content of my clipboard.

Comment 7

16 years ago
Oh, on Linux?  OK.
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta

Comment 8

16 years ago
Not really editor core.  Brade, do you know who owns this?
Assignee: jfrancis → brade

Comment 9

16 years ago
Akkana--can you look over this bug and explain to me the issue for linux?
Possibly this is a duplicate selection bug?
Component: Editor: Core → Selection
Hm... I can reproduce the _visual_ misdrawing of the selection, but the PRIMARY
contents are unaffected by it...

Comment 11

16 years ago
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.
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
  - 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

16 years ago
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)
Target Milestone: mozilla1.4beta → ---

Comment 14

16 years ago
resolving as invalid since I have gotten no clarification and others don't see
any problems with primary clipboard
Last Resolved: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.