464084 - Clicking Search button in search bar highlights the default text (browser.urlbar.clickSelectsAll = true)

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Shayne Jewers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081110 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081110 Minefield/3.1b2pre

"Google" (or whatever default text is in there) becomes highlighted when you click the search button, the first time you do it, without inserting text.

Reproducible: Always

Steps to Reproduce:
1.Click the search button in the search bar.

Actual Results:  
"Google" (or whatever text is in there) becomes highlighted

Expected Results:  
The text shouldn't be highlighted.

Comment 1

[Luke Iliffe (Harlequin99)]

Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre 

However I can only reproduce this on initial browser startup. Once the search button has been clicked once I cannot reproduce the issue.

Comment 2

[hhh]

Regression is between the Sep 27 and Sep 28 nightly builds.

Comment 1 is incorrect, this behavior continues until the search <em>field</em> is clicked once.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

that would be http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-27+02%3A00%3A00&enddate=2008-09-28+04%3A00%3A00

Comment 4

[Shayne Jewers]

hmm, my guess us Bug 457353 did it. Might be wrong though.

Comment 5

[Shayne Jewers]

this seems to have been fixed now?

Comment 6

[hhh]

Yes, confirmed re: comment #5. This bug can be closed.

Comment 7

[hhh]

re: comment #6, sorry, I'm still seeing this...

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081124 Minefield/3.1b2pre

Comment 8

[Shayne Jewers]

oh, whoops. yeah I can still see it. ccing justin wood as well since he worked on bug 457353, and I think that may have caused this.

Comment 9

[Justin Wood (:Callek)]

I would be surprised if Bug 457353 caused this... (I can look into it later if need be) bz any thoughts?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yeah, removal of an unused method doesn't seem like a likely culprit here.

That said, nothing in the range jumps out at me.  The simplest approach is to do some hg bisecting here to find the culprit changeset.

Justin, are you willing to do that?

Comment 11

[Justin Wood (:Callek)]

I won't have time for at least a two or three days, but provided I can repro when I get home from work, I am willing to...

Comment 12

[Dão Gottwald [:dao]]

not sure about the component... "Selection" seems to be the next best fit to me.

Comment 13

[Boris Zbarsky [:bzbarsky]]

That mostly depends on whether there's chrome JS calling select().

Still waiting on a regression range.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #13)
> That mostly depends on whether there's chrome JS calling select().

There is (for Mac and Windows):

http://hg.mozilla.org/mozilla-central/annotate/28f45bf33ba9/toolkit/content/widgets/textbox.xml#l237

http://hg.mozilla.org/mozilla-central/annotate/28f45bf33ba9/toolkit/content/widgets/textbox.xml#l281

Comment 15

[Boris Zbarsky [:bzbarsky]]

Well, in that case the bug could be in said chrome code or its caller, no?

Comment 16

[Boris Zbarsky [:bzbarsky]]

As in, this doesn't sound like a bug in the core "manage the ranges that make up the selection and paint the selection" codepaths.

Comment 17

[Dão Gottwald [:dao]]

(In reply to comment #15)
> Well, in that case the bug could be in said chrome code or its caller, no?

It could, but then I can't reproduce this on Linux with clickSelectsAll set to true.

I don't see any report that this happens OSX, thus setting OS to Win.
My new guess for the component would be widget: win32...

Comment 18

[Dão Gottwald [:dao]]

(In reply to comment #14)
> (In reply to comment #13)
> > That mostly depends on whether there's chrome JS calling select().
> 
> There is (for Mac and Windows):
> 
> http://hg.mozilla.org/mozilla-central/annotate/28f45bf33ba9/toolkit/content/widgets/textbox.xml#l237
> 
> http://hg.mozilla.org/mozilla-central/annotate/28f45bf33ba9/toolkit/content/widgets/textbox.xml#l281

It has to be the "click" event handler that selects the text in this case; if it was the "focus" event, the emptytext would have been cleared already.

Comment 19

[Jim Jeffery not reading bug-mail 1/2/11]

For what is worth.. I can no longer repo this using this build changeset:

http://hg.mozilla.org/mozilla-central/rev/9952fee851da

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081210 Minefield/3.2a1pre Firefox/3.0.4 ID:20081210040513

Comment 20

[Dão Gottwald [:dao]]

Err, I can actually reproduce this on Linux with the latest trunk nightly.

Comment 21

[Dão Gottwald [:dao]]

This is most likely a regression from bug 288194.

Comment 22

[Dão Gottwald [:dao]]

Attachment: patch

Comment 23

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/138f6ab12c35

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 352348 [details] [diff] [review]
patch

a191=beltzner

Comment 25

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/51be2316e268

Comment 26

[Aakash Desai [:aakashd]]

Verified FIXED on agent:
 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090302 Shiretoko/3.1b3pre