Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Unwanted Google searches due to mouse position.

RESOLVED FIXED in seamonkey2.17

Status

SeaMonkey
Location Bar
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bugzilla, Assigned: ewong)

Tracking

SeaMonkey 2.4 Branch
seamonkey2.17
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

6 years ago
Confirmed with
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110930 SeaMonkey/2.7a1
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

6 years ago
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?
(Reporter)

Comment 3

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

6 years ago
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.
(Reporter)

Comment 5

6 years ago
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
(Assignee)

Comment 6

5 years ago
Created attachment 679535 [details] [diff] [review]
Go directly to url when mouse-over google button and pressing enter. (v1)
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #679535 - Flags: review?(neil)

Comment 7

5 years ago
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.)
Attachment #679535 - Flags: review?(neil) → review-

Comment 8

5 years ago
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.
(Assignee)

Comment 9

5 years ago
Created attachment 680528 [details] [diff] [review]
Unwanted Google searches due to mouse position
Attachment #679535 - Attachment is obsolete: true
Attachment #680528 - Flags: feedback?(philip.chee)

Comment 10

5 years ago
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?
(Assignee)

Comment 11

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

Updated

5 years ago
Attachment #680528 - Flags: feedback?(philip.chee)
(Assignee)

Updated

5 years ago
Attachment #680528 - Flags: review?(neil)
Comment on attachment 680528 [details] [diff] [review]
Unwanted Google searches due to mouse position

Did you want to optimise selectedIndex in a separate bug?
Attachment #680528 - Flags: review?(neil) → review+
(Assignee)

Comment 13

5 years ago
(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.
(Assignee)

Comment 14

5 years ago
Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/a51b0d9414fd
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Target Milestone: --- → seamonkey2.17
You need to log in before you can comment on or make changes to this bug.