258287 - Selection effect without mouse drag after switching tabs & clicking textarea scrollbar

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Jeff Walden [:Waldo]]

This could very possibly be a duplicate as form selection bugs have been around
forever, but as the form code was forked from Mozilla last I knew, this is a
Firefox bug now.

The bug is completely reproducible.

Steps to reproduce:
1. Visit the URL (not every URL with a textarea works - I can't reproduce it on
the New bug page, for example).  Make sure another tab to another site is open
but not selected.  (I used
<http://www.meyerweb.com/eric/thoughts/2004/09/06/a-labor-day-weekend-of-love/>
when I reproduced the bug.)
2. Type some stuff in the comments box at end of page - type enough to get it to
start scrolling vertically.  Random text copied a bunch of times works fine.
3. Put the cursor at the end of the text with the mouse pointer.  Then click the
mouse off the textarea -- to the right of the textarea works fine.
4. Switch to the second tab and then switch back to the first tab.
5. Click on the vertical scrollbar for the comments textarea.
6. Move the mouse pointer to within the textarea (but not on the scrollbar).
7. Move the mouse pointer up and down to see selection from bottom of textarea
to wherever the mouse is located vertically.  Click to see the "selection"
disappear, replaced by a regular cursor at the location of the mouse pointer.

This is something I've never seen before with native forms (only XUL forms), and
it's rather disconcerting.  It's also something that can somewhat easily occur
accidentally -- it's taken me awhile to get a reproducible set of instructions
to demo the bug.

I've added the conversion keyword because I think screwy form selection is
something that's just odd enough to push away a potential user who doesn't like
the inconsistency with native behavior.

Comment 1

[Jeff Walden [:Waldo]]

Odd form selection effects in my opinion should have been eradicated long ago
for a Mozilla release.  Forms should act the way the users expects they will,
and this example certainly doesn't.

-->blocking-aviary1.0?

Comment 2

[chris hofmann]

unlikely there is enough time to work on this before 1.0.  renominate if a patch
appears.

Comment 3

[Soledad Penades [:sole] [:spenades]]

I do suffer the same. It's not necessary to switch tab, instead it's enough to
switch windows and then come back to firefox.
WXP Pro, Firefox1.0

Comment 4

[pile0nades]

I get this effect sometimes when reloading the edit page on wikipedia. Sometimes
(rarely) it even happens in input boxes! I can't believe this is still marked as
NEW since September 2004. It's almost September 2005 already, lets get this
f**ker fixed!

Comment 5

[Jorge Villalobos [:jorgev] (he/him)]

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

Comment 6

[pile0nades]

I have a simpler testcase. I think this is the same bug.

1. go to http://software.hixie.ch/utilities/cgi/data/data
2. click to the right of the textbox
3. mouse over the text box

The text gets selected as if you clicked and dragged in the box.

Comment 7

[Haudy Kazemi]

There is some discussion about this bug at http://forums.mozillazine.org/viewtopic.php?t=436884&start=30#2361717

pile0nades asked:
---
Does anyone see this bug:
1. Go here <my edit> it was a link to this URL:
data:text/html;charset=utf-8;base64,PHRleHRhcmVhIHN0eWxlPSJ3aWR0aDogMzAwcHg7IGhlaWdodDogMjAwcHg7IGRpc3BsYXk6IGJsb2NrOyBtYXJnaW46IDAgYXV0bzsiPjwvdGV4dGFyZWE%2B 
</my edit>
2. Type some random text so the spell checker underlines it in red.
3. Click to the left or right of the box and hover it.

The text should become selected in gray without clicking and dragging in the box, which is wrong. I tested this on a new profile. It is probably bug 285287.
---
My response:
I see it too, on BonEcho/2.0b1 ID:2006070805. Its description matches the bug report pretty well, although I couldn't reproduce it on the original example sites. (This is probably because the original sites have changed over the past 2 years and are no longer valid examples.  Alternatively, the original example sites showed problems in builds from the September 2004 timeframe, but not in current builds, because of some other confounding factors that have changed in Mozilla/Firefox since then.)

I would consider it a minor level bug that should be fixed for UI consistency and application polish.  (I hold that bad memory leaks and crashes are much more annoying than small UI glitches.  Thankfully recent Bon Echo builds have been getting a lot better with memory than some of the earlier Firefox releases.)

Comment 9

[Drew Willcoxon :adw]

I can't reproduce the test cases mentioned in this bug, and it's been a while, so optimistically marking WFM.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:23.0) Gecko/20130404 Firefox/23.0