This change brings back behavior introduced in r116244.
Created attachment 185506 [details] Patch
Comment on attachment 185506 [details] Patch As discussed offline this could still be improved. Clearing r? for now, see https://bugs.webkit.org/show_bug.cgi?id=93166 also for a previous discussion about that.
*** Bug 93166 has been marked as a duplicate of this bug. ***
Created attachment 186025 [details] Patch
Comment on attachment 186025 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=186025&action=review > Source/WebCore/inspector/front-end/FilteredItemSelectionDialog.js:247 > + score += ignoreCase ? 20 : 10; 10 : 20
Committed r141594: <http://trac.webkit.org/changeset/141594>
View in context: https://bugs.webkit.org/attachment.cgi?id=186025&action=review > LayoutTests/inspector/filtered-item-selection-dialog-filtering-expected.txt:12 > +Output:["abc","acB"] For Case sensitive matching I would expect Output: ["acB"] since abc does not match aB with case > LayoutTests/inspector/filtered-item-selection-dialog-filtering-expected.txt:32 > +Output:["fooBarBaz","foo_bar_baz","foobarBaz","foobarbaz","FooBarBaz","Foo_Bar_Baz","a fooBarBaz","aFooBarBaz","afooBarBaz"] For Camel case matching, I would not expect fBaB to match foo_bar_baz nor foobarBaz, foobarbaz FooBarBaz etc. To me the output should be Output:["fooBarBaz", "a fooBarBaz"]
Created attachment 186462 [details] screenshot of FilteredItemSelectionDialog Here is an example of how Bug 93166 isn't really a duplicate of this bug. The user types "all", the default selection ignores >all<InFile.html and >All<ExpresionsQuery.js but instead picks AdvancedSearchController.js. Relaxed matching is great because it helps the user explore the space quickly based on the character they know. Shortest match compliments this by defaulting to the most constrained match among all the relaxed matches.