Closed Bug 463635 Opened 16 years ago Closed 16 years ago

All Tabs search doesn't always update on Enter

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.1b2

People

(Reporter: dao, Assigned: dao)

References

Details

Attachments

(1 file, 1 obsolete file)

From bug 436304 comment 41: > * All Tabs search doesn't update on Enter. I.e. when searching a tab and > quickly hitting Enter, a different tab is selected than when shortly pausing > before hitting Enter.
Flags: blocking-firefox3.1?
Attached patch patch (obsolete) (deleted) — Splinter Review
Attachment #346894 - Flags: review?(gavin.sharp)
Comment on attachment 346894 [details] [diff] [review] patch >diff --git a/browser/base/content/browser-tabPreviews.js b/browser/base/content/browser-tabPreviews.js > case "keydown": > case "keyup": >+ if (event.keyCode == event.DOM_VK_RETURN) { >+ // If there's a pending search, kick it off now. >+ if (this.searchField._timer) >+ this.search(); When wouldn't there be a search pending here? And won't this mean we'll end up searching twice, once now and once when the timer fires? I guess selectThumbnail() closes the panel, which means the second search() will be a no-op because isOpen is false? >+ event.stopPropagation(); Why is this needed?
(In reply to comment #2) > >+ if (event.keyCode == event.DOM_VK_RETURN) { > >+ // If there's a pending search, kick it off now. > >+ if (this.searchField._timer) > >+ this.search(); > > When wouldn't there be a search pending here? When hitting Enter without entering a search term, or when hitting Enter after the timer has ended. > And won't this mean we'll end up searching twice, once now and once when the > timer fires? I guess selectThumbnail() closes the panel, which means the second > search() will be a no-op because isOpen is false? Yes, it would be a no-op, but this.searchField.value = "" in onPopupHidden would also cancel the timer. Also, if the keypress event reaches the textbox, the timer would be canceled and search() would be called immediately, which would be a no-op as well. > >+ event.stopPropagation(); > > Why is this needed? I think I wanted event.preventDefault() in order to suppress the keypress event, but this would leave the timer intact, so I can probably just remove that line.
Attached patch patch (deleted) — Splinter Review
without event.stopPropagation()
Attachment #346894 - Attachment is obsolete: true
Attachment #346947 - Flags: review?(gavin.sharp)
Attachment #346894 - Flags: review?(gavin.sharp)
Attachment #346947 - Flags: review?(gavin.sharp) → review+
Attachment #346947 - Flags: approval1.9.1b2?
Comment on attachment 346947 [details] [diff] [review] patch a=beltzner
Attachment #346947 - Flags: approval1.9.1b2? → approval1.9.1b2+
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b2
Flags: blocking-firefox3.1?
Flags: in-testsuite+
Verified with the following builds. The correct tab is chosen now even the search hasn't finished yet when pressing the Enter key. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre ID:20081112020254 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre ID:20081112034733
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: