306538 - Autocomplete doesn't work without a mousemove event

Status: RESOLVED FIXED

(Toolkit :: Autocomplete, defect)

Description

[Doug Turner (:dougt)]

It seams that the autocomplete widget will not work if it doesn't receive a
mousemove event.  There are some users that uses a pen or other device which
doesn't allow mouse movement or dragging.  

Basically in FireFox, if you use a tablet PC; or in Minimo on a phone or PDA,
you can click on the textbox type="autocomplete" widget, which brings up a popup
containing all of your history.  If you simple click without generating a
mousemove, the selected item would have never be selected and your click would
close the popup as a noop.

I think the fix is to treat the mousedown event in the same exact way as we do
the mousemove event.

I tested this theory out and it works find.  Basically what i did was on line
773 of mozilla/toolkit/content/widgets/autocomplete.xml, i duplicated the
mousemove handler and renamed one to be mousedown.  There might be a cleaner way
to do this.  Any suggestions, Mike?

Comment 1

[[e-mail]]

For my similar effect in bug 178091 I simply made the click do an extra update.

Comment 2

[Doug Turner (:dougt)]

Attachment: patch v.1

just duplicating the mousemove handler and naming it mousedown.  there is
probably a cleaner way.  this patch works for me.

Comment 3

[[e-mail]]

Comment on attachment 194666 [details] [diff] [review]
patch v.1

>+         var rc = this.getHoverCell(event);
>+         if (rc && rc.row != this.parentNode.currentIndex)
>+            this.parentNode.view.selection.select(rc.row);
I don't think you need to duplicate the whole method, just this bit.

Comment 4

[Doug Turner (:dougt)]

Attachment: patch v.2

Comment 5

[Doug Turner (:dougt)]

thanks mike:


Checking in content/widgets/autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v  <--  autocomplete.xml
new revision: 1.47; previous revision: 1.46
done

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase

I think this also fixed this testcase. Follow the steps in the testcase to
reproduce the bug.
This was a problem that also caught me quite often in the wild (probably had
gmail in a background tab).
So maybe this patch is also useful on branch?

Comment 7

[Asaf Romano (gone)]

Yeah, this testcase is now WFM

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050920
Firefox/1.6a1

Comment 8

[[e-mail]]

Sorry, this one slipped off my radar because I went on holiday
(and I'm still 75 bugmails behind, sigh...)

Comment 9

[Martijn Wargers (dead)]

I think this patch would be also very useful on branch.
I very much suspect it would also fix bug 249763 and bug 174489.
Doug, care to ask approval 1.8b5? for it?

Comment 10

[Doug Turner (:dougt)]

should be considered.  It is a low risk, high gain patch.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

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

Comment 12

[Ed Lee :Mardak]

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

Comment 13

[Ed Lee :Mardak]

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

Comment 14

[Ron Baldwin]

I'm nominating for the branch since this bug has:
   1) baked on the truck for over a month and a half
   2) is a low risk, high gain patch (comment 10)
   3) affects normal users, not just tablets, PDAs, etc. (see below)

Imagine you're using a well known form (e.g. a Bugzilla bug entry) and doing something you do all the time (e.g. add yourself to the CC list).  You click in the field, move the mouse to where you know the entry you want will be, hit the first letter of the entry and then click.  If you didn't happen to move the mouse after hitting the first letter, the textbox doesn't get filled in.

Here are the steps to reproduce:
1. Set focus to a textbox that has autocomplete entries.
2. Position the mouse such that it will be over an entry from the dropdown when it appears.
3. Enter a character that will cause autocomplete to show. *Do not move the mouse*.
4. Click without moving the mouse.  Since the entries highlight on mouse move, no entry will be selected.  Clicking will dismiss the dropdown without populating the textbox.

These steps may seem somewhat contrived, but it happens (at least to me) more often than one might think.

Comment 15

[Reed Loden [:reed]]

Ron,
To request 1.8 branch approval of this patch, you need to set the "approval1.8rc2" flag on the patch to '?'. "blocking1.8rc2" is just used for tagging the actual bug that blocks the said release, not for approval of the patch into the branch.

Comment 16

[Ron Baldwin]

(In reply to comment #15)
> Ron,
> To request 1.8 branch approval of this patch, you need to set the
> "approval1.8rc2" flag on the patch to '?'. "blocking1.8rc2" is just used for
> tagging the actual bug that blocks the said release, not for approval of the
> patch into the branch.

I'd set the approval flag on the patch, but I don't have rights (which seems silly that I can nominate a bug to block, but not nominate a patch to land--but I digress).

Anyone with rights want to set the flag?

Comment 17

[Ron Baldwin]

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

Comment 18

[Scott MacGregor]

This isn't a show stopper which would cause us to respin the final 1.5 bits.

Comment 19

[Steffen Wilberg]

Comment on attachment 194715 [details] [diff] [review]
patch v.2

We should take this on the branch for Firefox 2.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Checked this in on the branch for Firefox 2.
mozilla/toolkit/content/widgets/autocomplete.xml; new revision: 1.44.2.4;

Comment 21

[Daniel Veditz [:dveditz]]

Doesn't appear to fit the criteria for a security/stability release