931386 - [ruleview] Add search UI to filter properties, similar to computed view

Status: RESOLVED DUPLICATE of bug 1120616

(DevTools :: Inspector, defect)

Description

[Brian Grinstead [:bgrins]]

Attachment: filterrules.png

As proposed by @jadmi_m on Twitter (https://twitter.com/jadmi_n/status/393814782505021440).  The idea is to add a search box that lets you limit the visible properties applied to an element in the rule view.  

The UI would have to be a little more complicated than it is for the computed view, since the filter has to still show applied rules (but only ones that have property name/values that match the search term).  Also, it should be clear that the filter is applied so that you aren't confused if you forget it is applied.

Another question: would the filter stay applied as you switch elements?

I"ve attached a screenshot from Andrzej of what dragonfly does (can play around with this in version 12 of Opera).

Comment 1

[randal]

In Computed tab filter field is already on bottom. But it's important to filter bar in Rules to be on TOP. It's far more intuitive and better to view/read.

If you still don't convinced or don't know. Download Opera 12.x and play around with this. 
This is the only thing that missing for me to switch from Dragonfly(Opera) to Firefox after 10 years! when I left Firefox for Opera and now its time for me for getting back. Normally I would choose Chrome, but JUST BECAUSE OF DEVELOPERS TOOLS you created. Also performance improvements in last few releases of Firefox is another most important matter.  

Mostly I'm a designer and html/css inspector is most used tool for me. That's why this filter is so important to QUICK workflow.

Comment 2

[Paul Rouget [:paul]]

For now, for consistency, we should build it at the bottom. I'm not against moving both search bars to the top. But this will need UX validation (and mockups) and it will happen in a different bug.

Comment 3

[randal]

Thanks for answer Paul.

However, but if it can be done it's super nice! Even in order you proposed.

Why it's so obvious both should be on top? 

#1 When you inspect element with a lots of rules and you know you are interested only changing for example padding. First thing you do is using filter instead wasting time to stroll and use your eyes to find out interesting rules. 

It's even more important when debugging. I mean when try to find, few padding properties in different files that override  or mess on each other. Then you can get quick overview all of filtered rules in different files to clean up or resolve problems. 

#2 After type in search filter list usually become small, and on bottom is white gap. So we must jumping through this gap from filter to results on top. It is not cool, because we read from top to bottom, and want results right under field.

I really don't know who and why place this filter in Computed on bottom. But hope it ca be also moved in next step as you said Paul.

Comment 4

[Paul Rouget [:paul]]

Related: bug 935803