Filtering/searching

[auchenberg]

A nifty feature would be to be able to filter/search. Imagine you wanna look up something with stylesheets, you type "stylesheets" and it filters the methods/events that has a name or property matching.

Would be extremely useful when looking up stuff, and should be relatively easy, as we have all the data available in protocol.json

[paulirish]

Yeah good call. "Cross-domain" filter for sure.

Perhaps match on all fields? (for "stylesheet" it would have 16 matches, which seems OK for such a common thing.

[auchenberg]

Yeah, it should simply filter on all property name and values.

[kdzwinel]

I was thinking how to implement that and I figured out we need a polymer component that:

• loads protocol.json via AJAX
• (caches it in the localStorage - not sure about that one)
• when user starts typing, displays all matching entries
• and redirects user to the clicked entry.

As for the UI, I really like search widget in the polymer docs: https://www.polymer-project.org/1.0/docs/devguide/feature-overview.html .

[kdzwinel]

Eric agreed to work on that :clap:

[ericguzman]

Just so I don't miss something, are these all the protocol.json properties that should be used in filtering:

Domains

• Domain names
• Domain descriptions

Types

• Type ids
• Type properties

Commands

• Command names
• Command descriptions
• Command parameter names

Events

• Event names
• Event parameter names

Also, I'm thinking we might be able to write a utility (like the existing create-domain-files.js) that saves us from loading the entire protocol json file. Any thoughts?

[kdzwinel]

IMO searching inside descriptions and property names will create a lot of false positives. Maybe lets limit the first version of search to names/ids? If we find it too limited it should be easy enough to add descriptions and property names later on. What do you think?

utility that saves us from loading the entire protocol json file

That's a great idea. protocol.json is huge and I started thinking about caching it in localstorage (after initial load), but this solution has a lot of drawbacks (keeping it up to date, initial load v.long). If we create a separate json, limited to data that search actually needs, we should be able to get away with relying on browser cache. We can probably even embed it in HTML.

[paulirish]

Tossing the protocol in sessionstorage seems like a decent eviction policy for us.

I'm +1 on descriptions+property names, but it will require some use and feedback either way.

excited for this one!

[ericguzman]

Sorry for being out of the loop, but by eviction policy do you mean temp solution?

I've started with a two-part solution that I'll push to a branch soon -- still using a smaller search index rather than the entire json file, but only aggregating "primary" keywords (which are domain, method, type, and event names). @kdzwinel had a good point about false positives in descriptions, so we might want something a bit more sophisticated to handle those keywords (in part two of this feature).

[paulirish]

i was just saying that if there was a concern about fetching protocol.json on every pageload we could cache it in sessionstorage.

the above sgtm

[ericguzman]

Hi guys,

I've got a mostly-done version of Search working. Check it out here: https://ericguzman.github.io/debugger-protocol-viewer/

Let me know if run into any issues, or have any suggestions while I'm putting the final bit of polish on it + testing cross-browser.

[paulirish]

bug: I would expect power would include results for the canProfilePower method

Outside of this, it's looking great. nice one.

[kdzwinel]

Whoa, this looks great! Awesome job :+1:

Small issues that I found:

• when there are no results we should show some kind of a message or hide the white results box all together
• when you search for something from the same page that you are currently browsing and click on the search result the results list should close (e.g. try searching and clicking on getResourceTree while being on the /debugger-protocol-viewer/Page page).
• if <input type=search was used instead of <input type=text we would get a native clear button for free
• it wasn't obvious for me how to close the search results list, but maybe it's just me

[auchenberg]

Looks great!

A little feature request: When searching for "css.enable" (.<event/method>, I would love the relevant section to show up. This would super useful when inspecting the WebSocket traffic/debugging the traffic.

[paulirish]

@ericguzman would love to get this this work updated and merged when you get a moment

[ericguzman]

@paulirish Been tied up with work work, but I'll merge the update with bug fixes/feature requests in the next couple days.

[kdzwinel]

Search landed :fireworks: Should we close this task? IMO all further improvements should get separate tickets.

[paulirish]

yup!