GNOME Bugzilla – Bug 673233
Tries to launch gnome-contacts on empty search resuts
Last modified: 2012-04-07 13:17:22 UTC
gnome-shell-3.4.0-1.fc17.x86_64 1. In the overview, start typing a number 2. See contacts appear in the search results (matching the phone numbers I would guess) 3. Type digits until no more search results appear 4. Press Enter What happens: - Tries to launch gnome-contacts with the last matched contact (even though it's already been removed from the list of search results) What should happen: - Nothing, there's no results matching
Can you reproduce this consistently? BTW, what should happen isn't nothing[1], it should actually launch a wikipedia or google search since the default target for activation should be one of those buttons. [1] Though you can argue that that's what should happen and I'd agree...
(In reply to comment #1) > Can you reproduce this consistently? Yep. I'll let you decide what the good behaviour is, the bad one if definitely there though.
This happens not just for contacts, but any app. Typing "fooooooo" and pressing enter brings me Swell Foop.
Created attachment 211385 [details] [review] The new gnome-documents search provider wasn't being picked up on my environment and that's why I couldn't reproduce this. -- searchDisplay: Update the selection for async searches without results This ensures that the initial selection is always set correctly. We were missing the empty async search results case.
Review of attachment 211385 [details] [review]: ::: js/ui/searchDisplay.js @@ -434,3 @@ } - this._maybeSetInitialSelection(); Why this removal? If the user doesn't have any async search providers, or we never get a reply back from gnome-documents even while we're showing other items, we will fail to set the initial selection, won't we?
(In reply to comment #5) > ::: js/ui/searchDisplay.js > @@ -434,3 @@ > } > > - this._maybeSetInitialSelection(); > > Why this removal? If the user doesn't have any async search providers, or we > never get a reply back from gnome-documents even while we're showing other > items, we will fail to set the initial selection, won't we? We can certainly leave it there but it seems pointless to me since the for loop right before it is calling _updateProviderResults() which now calls _maybeSetInitialSelection unconditionally.
Review of attachment 211385 [details] [review]: Oh, whoops, I misread the patch, then... I thought _maybeSetInitialResults was still inside the if (provider.async) branch.