Open
Bug 908307
Opened 11 years ago
Updated 2 years ago
[Meta] Implement new devtools search and filter specs
Categories
(DevTools :: Inspector, enhancement, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: codacodercodacoder, Unassigned)
References
(Depends on 4 open bugs)
Details
(Keywords: meta)
Attachments
(1 file)
(deleted),
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130814063812 Steps to reproduce: 1 - Type stuff into search box (dropdown list appears with matches) - Arrow-down using keyboard 2 - Entering long ids (and listing them in the dropdown) does not scale Actual results: 1 - My search text gets wiped which means retyping the whole thing (possibly) 2 - for common/frequently used text in the page, the list is long... if the search text is long (I dunno, 20/30+ chars?) the list shows only the left most chars which is common to all of them... making it useless as a selection mechanism Expected results: Both 1 and 2 would be improved if HTML panel was live-scrolled to the matching HTML as I arrow-down the list Also, leave my entered search text as is Also, make the search box a LOT wider (or make it flex)
And make the placeholder hint at the expected input being a selector. I had no idea it expected $() kind of input.
Updated•11 years ago
|
Component: Untriaged → Developer Tools: Inspector
Comment 2•11 years ago
|
||
(In reply to Russ from comment #0) > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 > Firefox/23.0 (Beta/Release) > Build ID: 20130814063812 > Btw, I recommend Firefox Nightly if you're a dev, latest improvements usually come there. > > 1 - My search text gets wiped which means retyping the whole thing (possibly) > > 2 - for common/frequently used text in the page, the list is long... if the > search text is long (I dunno, 20/30+ chars?) the list shows only the left > most chars which is common to all of them... making it useless as a > selection mechanism Yep I get this issue too but after a very long string. > Both 1 and 2 would be improved if HTML panel was live-scrolled to the > matching HTML as I arrow-down the list Yep, this would be nice to have. > Also, make the search box a LOT wider (or make it flex) Hmm.. I should experiment with that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is being addressed here, it seems: https://bugzilla.mozilla.org/show_bug.cgi?id=835896
Updated•9 years ago
|
Priority: -- → P3
Comment 4•8 years ago
|
||
This rather sounds like a meta-bug for several smaller UX improvements. In order to make progress on this and allow implementing these improvements separately, should individual bugs be created for them blocking this one? Sebastian
Flags: needinfo?(chevobbe.nicolas)
Comment 5•8 years ago
|
||
(In reply to Sebastian Zartner [:sebo] from comment #4) > This rather sounds like a meta-bug for several smaller UX improvements. In > order to make progress on this and allow implementing these improvements > separately, should individual bugs be created for them blocking this one? > > Sebastian Indeed, it makes sense. I don't have time ATM, but I will file these bugs later today. Thanks
Flags: needinfo?(chevobbe.nicolas)
Summary: Make DevTools "Search HTML" filter box UX better → [META] Make DevTools "Search HTML" filter box UX better
Updated•8 years ago
|
Summary: [META] Make DevTools "Search HTML" filter box UX better → [Meta] Make DevTools "Search HTML" filter box UX better
Updated•8 years ago
|
Summary: [Meta] Make DevTools "Search HTML" filter box UX better → [Meta] Implement new devtools search and filter specs
Comment 6•8 years ago
|
||
Hm... I'd potentially like a lot of eyes on this, Brian. What's the best way to go about that?
Attachment #8751961 -
Flags: review?(bgrinstead)
Comment 7•8 years ago
|
||
(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #6) > Created attachment 8751961 [details] > search-and-filter-spec.png > > Hm... I'd potentially like a lot of eyes on this, Brian. What's the best way > to go about that? Easiest way I can think of is to post dev-developer-tools
Comment 8•8 years ago
|
||
Summary from bug 1272254: The features of the search field widget include: - single content search - multiple content search (i.e. 'search all files') - search options - search suggestions - showing number matches - indication for no matches - focus shortcut - clearing the field - go to line feature (might be in a specialized widget; triggered through some special option [like typing a colon as in Debugger]) The features of the filter field widget include: - filter options - showing hint that items are filtered out and/or their number - indication for no matches - focus shortcut - clearing the field Sebastian
Comment 10•8 years ago
|
||
Sebastian, I agree on many of those features but I don't think we need all of them from the start. Some of them won't be concerned with this at all, but with how the tool integrates search. I do feel like there's another option for the searching UI: instead of a dedicated field, it's a wide popup field invoked by something like ctrl+p and autocompletes the search. The difference is that it can take up the whole screen and show a lot more info. Not sure if I'm missing some use cases though.
Comment 11•8 years ago
|
||
(In reply to James Long (:jlongster) from comment #10) > Sebastian, I agree on many of those features but I don't think we need all > of them from the start. Some of them won't be concerned with this at all, > but with how the tool integrates search. Sure, feel free to split those features out into individual bugs. The number of matches could be one of them, for example. Though we should try to avoid regressing existing features in the first version. > I do feel like there's another option for the searching UI: instead of a > dedicated field, it's a wide popup field invoked by something like ctrl+p > and autocompletes the search. The difference is that it can take up the > whole screen and show a lot more info. Not sure if I'm missing some use > cases though. I'm not sure how you imagine this UI to look like but maybe it goes into the direction of bug 1026479. What info do you imagine to see in there, which you don't get with the normal search field? Sebastian
Comment 12•8 years ago
|
||
(In reply to Sebastian Zartner [:sebo] from comment #11) > (In reply to James Long (:jlongster) from comment #10) > > Sebastian, I agree on many of those features but I don't think we need all > > of them from the start. Some of them won't be concerned with this at all, > > but with how the tool integrates search. > > Sure, feel free to split those features out into individual bugs. The number > of matches could be one of them, for example. > Though we should try to avoid regressing existing features in the first > version. The new interface is not going to match 1:1 with everything from the start. There are going to be new features and probably some smaller features from the old one missing. Part of that is because we want to actually avoid current features which is confusing, but also because we can't do everything in the first version. > > > I do feel like there's another option for the searching UI: instead of a > > dedicated field, it's a wide popup field invoked by something like ctrl+p > > and autocompletes the search. The difference is that it can take up the > > whole screen and show a lot more info. Not sure if I'm missing some use > > cases though. > > I'm not sure how you imagine this UI to look like but maybe it goes into the > direction of bug 1026479. > What info do you imagine to see in there, which you don't get with the > normal search field? Pretty much what Cmd+P looks like in Chrome. It's totally different than anything we have right now. There aren't any screenshots in that bug so I'm not sure what that looks like.
Comment 13•8 years ago
|
||
There's some interesting discussion in here around Cmd+P which my current doc doesn't recognize—I should mention that this is still a work in progress and still under review, so I'll definitely be updating the doc to reflect that kind of searching as well.
Comment 14•8 years ago
|
||
(In reply to James Long (:jlongster) from comment #12) > (In reply to Sebastian Zartner [:sebo] from comment #11) > > (In reply to James Long (:jlongster) from comment #10) > > > I do feel like there's another option for the searching UI: instead of a > > > dedicated field, it's a wide popup field invoked by something like ctrl+p > > > and autocompletes the search. The difference is that it can take up the > > > whole screen and show a lot more info. Not sure if I'm missing some use > > > cases though. > > > > I'm not sure how you imagine this UI to look like but maybe it goes into the > > direction of bug 1026479. > > What info do you imagine to see in there, which you don't get with the > > normal search field? > > Pretty much what Cmd+P looks like in Chrome. It's totally different than > anything we have right now. There aren't any screenshots in that bug so I'm > not sure what that looks like. Ah, you mean the sources filter. (In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #13) > There's some interesting discussion in here around Cmd+P which my current > doc doesn't recognize The doc here not, though you already created a filter field in https://projects.invisionapp.com/share/9G5R8XCYZ#/screens/117937554. And I believe that's all that's needed. No need for a popup panel like in Chrome. Sebastian
Comment 15•8 years ago
|
||
Comment on attachment 8751961 [details]
search-and-filter-spec.png
Clearing Brian's review since there are some changes I'd like to make to this.
Attachment #8751961 -
Flags: review?(bgrinstead)
Comment 16•8 years ago
|
||
The reason why the overlay (opened with cmd+P) is nice is because: * Many developers are used to it, most modern editors have that sort of file-finder popup * It can span about 70% of the width of the screen, making room to show a lot of data like long paths which is important when looking for files in a large codebase * It does not take up room in the UI when not in use. I can see why a dedicated filter box is nice, usually because it's filtering a component directly (filter the variables view, the net monitor table, etc). But we don't want to actually filter the sources tree, because it's a tree and should not lose its state. Additionally, we probably want to include *other* results in the list, like function definitions. So this is more of a global search component not tied to anything specific in the UI. We should leave it up to Helen as to what the final designs are. There may be other ways to do it, and Helen has a sense for what all tools need to how to consolidate the UX across them. I'm fine if it's not a popup, but I would like to take into account the benefits that it brings and cater to them a bit (particularly the fact that it can be really wide).
Reporter | ||
Comment 17•8 years ago
|
||
@James That sounds as though it's going to hide the page as presented. In my OP, I'd specifically stated in the "Expected Results" that live-scrolling to the match (in the *inspector*) being the way to go. Now, well, the "bug" seems to be about something else entirely - it's been hijacked. Am I supposed enter it again? Maybe the "new devtools search and filter specs" will solve all of these problems, but that's not clear to me.
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•6 years ago
|
Type: defect → enhancement
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•