Last Comment Bug 690745 - Unwanted Google searches due to mouse position.
: Unwanted Google searches due to mouse position.
Status: RESOLVED FIXED
:
Product: SeaMonkey
Classification: Client Software
Component: Location Bar (show other bugs)
: SeaMonkey 2.4 Branch
: x86 Windows XP
: -- normal (vote)
: seamonkey2.17
Assigned To: Edmund Wong (:ewong)
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-30 06:20 PDT by bugzilla
Modified: 2013-01-08 08:38 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Go directly to url when mouse-over google button and pressing enter. (v1) (1.25 KB, patch)
2012-11-07 20:39 PST, Edmund Wong (:ewong)
neil: review-
Details | Diff | Splinter Review
Unwanted Google searches due to mouse position (946 bytes, patch)
2012-11-11 21:24 PST, Edmund Wong (:ewong)
neil: review+
Details | Diff | Splinter Review

Description bugzilla 2011-09-30 06:20:51 PDT
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110923 Firefox/7.0 SeaMonkey/2.4
Build ID: 20110923012712

Steps to reproduce:

Type something in the address bar, move the mouse over the "search Google for..."-button at the bottom of the list and press enter.

(it doesn't malfunction when hovering over any of the suggested URLs, only when hovering over the 'search Google'-button at the bottom of the list.)

It happens to me often when I click the address bar and move the mouse pointer out of the way so I can see what I am typing. The mouse pointer happens to end up just below the address bar, at the location where the "search Google" button appears while typing.


Actual results:

I'm being taken to a Google page on the URL I just entered.


Expected results:

I should have been taken to the URL I entered. I pressed enter, I did not click the mouse.
Comment 1 Philip Chee 2011-09-30 07:41:26 PDT
Confirmed with
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110930 SeaMonkey/2.7a1
Comment 2 Karsten Düsterloh 2011-09-30 10:09:07 PDT
I ran into that myself during the couple of months, but I don't remember this  being "since always". So, is this a regression? Can we pin down a regression range?
Comment 3 bugzilla 2011-10-01 06:49:37 PDT
I still use a Seamonkey 1.1.17 at home (I love the Quick Launch too much) and just confirmed that it also has this bug. I hardly run into it there though. Maybe the mouse on the other PC is slightly different.

On 1.1.17, when the button appears below the mouse, it doesn't become highlighted until I move the mouse and I need to move it quite a distance. I can move the mouse over the text without highlighting the button. The pointer has to move in or out of the margin (4px?) between text field and buttons edge.
The button has to be highlighted for the unwanted search to happen.

I think I remember the button becomes highlighted in Seamonkey 2.4 as soon as it appears, without me having to move the mouse, but I'm not sure. (I'll check on monday.) That might explain why I didn't notice it in Seamonkey 1.

So the bug has been there for years, although I'm not yet sure it occurred as easily as it does in recent Seamonkeys.
Comment 4 Philip Chee 2011-10-01 08:52:19 PDT
Hmm. In SeaMonkey 2.0 we moved to using the Firefox "Smart Location Bar" functionality, although not their UI.
Then in SeaMonkey 2.1 we rewrote our search functionality using the OpenSearch search plugins.
Two points to look at for what if anything changed.
Comment 5 bugzilla 2011-10-03 00:22:30 PDT
In Seamonkey 2.4, moving the mouse pointer a single pixel is enough to trigger the problem.

The vibration of my desk, stiffness of the mouse cord or even just the different mouse brands could all be the reason I didn't notice this issue in Seamonkey 1.x
Comment 6 Edmund Wong (:ewong) 2012-11-07 20:39:21 PST
Created attachment 679535 [details] [diff] [review]
Go directly to url when mouse-over google button and pressing enter. (v1)
Comment 7 neil@parkwaycc.co.uk 2012-11-08 00:27:12 PST
Comment on attachment 679535 [details] [diff] [review]
Go directly to url when mouse-over google button and pressing enter. (v1)

This looks as if it would completely break URLbar search; selectedIndex is 0 when the search option is highlighted and -1 when it isn't. (-1 is already tested for on line 384.)
Comment 8 neil@parkwaycc.co.uk 2012-11-08 02:50:11 PST
As far as I can tell, what seems to be happening is that opening the popup now causes a mouseover event that didn't happen previously. This confuses the urlbar binding into thinking that the mouse has moved when it hasn't. Switching from mouseover to mousemove should resolve the problem, at least until opening a popup causes a mousemove event ;-)

Since there will be more mousemove events than mouseover events it might be worth adding a check in the setter to avoid doing work when the mouse is just moving over the selected index but then again it might not.
Comment 9 Edmund Wong (:ewong) 2012-11-11 21:24:14 PST
Created attachment 680528 [details] [diff] [review]
Unwanted Google searches due to mouse position
Comment 10 Philip Chee 2012-11-17 06:52:15 PST
Comment on attachment 680528 [details] [diff] [review]
Unwanted Google searches due to mouse position

Doesn't appear to have any effect. Problem is still there. How did you test this?
Comment 11 Edmund Wong (:ewong) 2012-11-22 06:28:50 PST
I admit that I tried it and didn't work, but wasn't sure if it was my machine or the patch.  Now I know it's the patch that doesn't work, I'm completely lost as to how to fix this.
Comment 12 neil@parkwaycc.co.uk 2012-12-17 09:58:59 PST
Comment on attachment 680528 [details] [diff] [review]
Unwanted Google searches due to mouse position

Did you want to optimise selectedIndex in a separate bug?
Comment 13 Edmund Wong (:ewong) 2012-12-17 19:44:35 PST
(In reply to neil@parkwaycc.co.uk from comment #12)
> Comment on attachment 680528 [details] [diff] [review]
> Unwanted Google searches due to mouse position
> 
> Did you want to optimise selectedIndex in a separate bug?

Sure.
Comment 14 Edmund Wong (:ewong) 2012-12-17 20:02:14 PST
Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/a51b0d9414fd

Note You need to log in before you can comment on or make changes to this bug.