Closed
Bug 464084
Opened 16 years ago
Closed 16 years ago
Clicking Search button in search bar highlights the default text (browser.urlbar.clickSelectsAll = true)
Categories
(Toolkit :: UI Widgets, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: shayne.anthony.jewers, Assigned: dao)
References
Details
(Keywords: regression, verified1.9.1)
Attachments
(1 file)
726 bytes,
patch
|
enndeakin
:
review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
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•16 years ago
|
||
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.
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•16 years ago
|
||
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•16 years ago
|
||
hmm, my guess us Bug 457353 did it. Might be wrong though.
Reporter | ||
Updated•16 years ago
|
Keywords: regression
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•16 years ago
|
Version: unspecified → Trunk
Reporter | ||
Comment 5•16 years ago
|
||
this seems to have been fixed now?
Yes, confirmed re: comment #5. This bug can be closed.
Reporter | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
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•16 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 → ---
Updated•16 years ago
|
Status: REOPENED → NEW
Comment 9•16 years ago
|
||
I would be surprised if Bug 457353 caused this... (I can look into it later if need be) bz any thoughts?
Comment 10•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
Keywords: regressionwindow-wanted
Assignee | ||
Updated•16 years ago
|
Component: Search → General
Product: Firefox → Core
QA Contact: search → general
Assignee | ||
Comment 12•16 years ago
|
||
not sure about the component... "Selection" seems to be the next best fit to me.
Component: General → Selection
QA Contact: general → selection
Comment 13•16 years ago
|
||
That mostly depends on whether there's chrome JS calling select(). Still waiting on a regression range.
Assignee | ||
Comment 14•16 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
Comment 15•16 years ago
|
||
Well, in that case the bug could be in said chrome code or its caller, no?
Comment 16•16 years ago
|
||
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•16 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•16 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.
Comment 19•16 years ago
|
||
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•16 years ago
|
||
Err, I can actually reproduce this on Linux with the latest trunk nightly.
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Updated•16 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•16 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•16 years ago
|
||
Attachment #352348 -
Flags: review?(enndeakin)
Assignee | ||
Updated•16 years ago
|
Version: Trunk → 1.9.1 Branch
Updated•16 years ago
|
Attachment #352348 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 23•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/138f6ab12c35
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Updated•16 years ago
|
Attachment #352348 -
Flags: approval1.9.1?
Comment 24•16 years ago
|
||
Comment on attachment 352348 [details] [diff] [review] patch a191=beltzner
Attachment #352348 -
Flags: approval1.9.1? → approval1.9.1+
Assignee | ||
Comment 25•16 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/51be2316e268
Keywords: fixed1.9.1
Comment 26•15 years ago
|
||
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
Updated•15 years ago
|
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•