The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Toolkit
XUL Widgets
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: Shayne Jewers, Assigned: dao)

Tracking

({regression, verified1.9.1})

1.9.1 Branch
mozilla1.9.2a1
regression, verified1.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

9 years ago
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.
that would be http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-27+02%3A00%3A00&enddate=2008-09-28+04%3A00%3A00
(Reporter)

Comment 4

9 years ago
hmm, my guess us Bug 457353 did it. Might be wrong though.
(Reporter)

Updated

9 years ago
Keywords: regression

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

9 years ago
Version: unspecified → Trunk
(Reporter)

Comment 5

9 years ago
this seems to have been fixed now?

Comment 6

8 years ago
Yes, confirmed re: comment #5. This bug can be closed.
(Reporter)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME

Comment 7

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

Comment 8

8 years ago
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
I would be surprised if Bug 457353 caused this... (I can look into it later if need be) bz any thoughts?
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?
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...
(Assignee)

Updated

8 years ago
Keywords: regressionwindow-wanted
(Assignee)

Updated

8 years ago
Component: Search → General
Product: Firefox → Core
QA Contact: search → general
(Assignee)

Comment 12

8 years ago
not sure about the component... "Selection" seems to be the next best fit to me.
Component: General → Selection
QA Contact: general → selection
That mostly depends on whether there's chrome JS calling select().

Still waiting on a regression range.
(Assignee)

Comment 14

8 years ago
(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
Well, in that case the bug could be in said chrome code or its caller, no?
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.
(Assignee)

Comment 17

8 years ago
(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...
Component: Selection → General
OS: All → Windows XP
QA Contact: selection → general
(Assignee)

Comment 18

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

Comment 20

8 years ago
Err, I can actually reproduce this on Linux with the latest trunk nightly.
OS: Windows XP → All
Hardware: PC → All
(Assignee)

Updated

8 years ago
Summary: Clicking Search button in search bar highlights the default text in there → Clicking Search button in search bar highlights the default text (browser.urlbar.clickSelectsAll = true)
(Assignee)

Comment 21

8 years ago
This is most likely a regression from bug 288194.
Assignee: nobody → dao
Blocks: 288194
Component: General → XUL Widgets
Keywords: regressionwindow-wanted
Product: Core → Toolkit
QA Contact: general → xul.widgets
(Assignee)

Comment 22

8 years ago
Created attachment 352348 [details] [diff] [review]
patch
Attachment #352348 - Flags: review?(enndeakin)
(Assignee)

Updated

8 years ago
Version: Trunk → 1.9.1 Branch

Updated

8 years ago
Attachment #352348 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 23

8 years ago
http://hg.mozilla.org/mozilla-central/rev/138f6ab12c35
Status: NEW → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
(Assignee)

Updated

8 years ago
Attachment #352348 - Flags: approval1.9.1?
Comment on attachment 352348 [details] [diff] [review]
patch

a191=beltzner
Attachment #352348 - Flags: approval1.9.1? → approval1.9.1+
(Assignee)

Comment 25

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/51be2316e268
Keywords: fixed1.9.1
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.