Closed Bug 973588 Opened 12 years ago Closed 12 years ago

DXR search input field should be focused after load

Categories

(Webtools Graveyard :: DXR, defect)

Product:
Webtools Graveyard
Component:
DXR
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gfritzsche, Assigned: ehsan.akhgari)

Details

* Navigate to dxr.mozilla.org * Start typing * Nothing happens Ideally the search input field would be focused right away to enter a search query.
I remember writing this patch in one of the older UIs. :-) https://github.com/mozilla/dxr/pull/245
Assignee: nobody → ehsan
(Also, what's with the <tag /> XHTML-isms there? ;-)
We actually specifically disabled this in the new UI. In terms if the HTML style, I prefer to write it strictly even though the HTML5 doctype is forgiving ;)
(In reply to Schalk Neethling [:espressive] from comment #3) > We actually specifically disabled this in the new UI. Hm, why?
(In reply to Georg Fritzsche [:gfritzsche] from comment #4) > (In reply to Schalk Neethling [:espressive] from comment #3) > > We actually specifically disabled this in the new UI. > > Hm, why? Here you go: https://bugzilla.mozilla.org/show_bug.cgi?id=936199
For the DXR landing page this seems like a trade-off to support one specific use-case. Do you know that most people actually want to navigate the directory listing via type-to-select? I would expect most usage on dxr.mozilla.org/ to start off in the search box, but i'm of course biased by my own usage :)
OS: Mac OS X → All
(In reply to Georg Fritzsche [:gfritzsche] from comment #6) > For the DXR landing page this seems like a trade-off to support one specific > use-case. > Do you know that most people actually want to navigate the directory listing > via type-to-select? I suspect they don't! The whole purpose behind having a search interface is that it makes browsing through things manually mostly unnecessary. I think we should revert that "fix". (In reply to Schalk Neethling [:espressive] from comment #3) > In terms if the HTML > style, I prefer to write it strictly even though the HTML5 doctype is > forgiving ;) You've gotten things backwards! HTML5 (which is what is selected in the doctype) does not require these /> hunks, but it's forgiving enough to ignore them when you add them. This is a left over from the XHTML days when people tried to close the tags that did not have explicit HTML close tags this way. It is serving no purpose today in HTML5 documents.
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailapocalypse) from comment #7) > I think we should revert that "fix". It actually was autofocusing at the start and then changed. I cannot comment on the user base that would prefer one over the other and I would defer that to :ErikRose > You've gotten things backwards! Indeed I did, I still prefer self closing and closing tags in general. It is a matter of preference really.
(In reply to comment #8) > (In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, > emailapocalypse) from comment #7) > > > I think we should revert that "fix". > > It actually was autofocusing at the start and then changed. I cannot comment on > the user base that would prefer one over the other and I would defer that to > :ErikRose I know, because I wrote the original patch to autofocus this! :-) Let's wait to see why Erik took it out. > > You've gotten things backwards! > > Indeed I did, I still prefer self closing and closing tags in general. It is a > matter of preference really. I guess so. It makes me sick because it reminds me of the dark old days of XHTML. ;-) But I don't hold a very big horse in this race.
(In reply to Schalk Neethling [:espressive] from comment #5) > (In reply to Georg Fritzsche [:gfritzsche] from comment #4) > > (In reply to Schalk Neethling [:espressive] from comment #3) > > > We actually specifically disabled this in the new UI. > > > > Hm, why? > > Here you go: > https://bugzilla.mozilla.org/show_bug.cgi?id=936199 I think that bug is for not auto-focusing on indexed pages, which I agree is what we should we do. However, for the landing page we should definitely be auto-focused on the search box. I guess it is not easy to distinguish which is which now, but we should be able to hack that.
(In reply to Nick Cameron [:nrc] from comment #10) > (In reply to Schalk Neethling [:espressive] from comment #5) > > (In reply to Georg Fritzsche [:gfritzsche] from comment #4) > > > (In reply to Schalk Neethling [:espressive] from comment #3) > > > > We actually specifically disabled this in the new UI. > > > > > > Hm, why? > > > > Here you go: > > https://bugzilla.mozilla.org/show_bug.cgi?id=936199 > > I think that bug is for not auto-focusing on indexed pages, which I agree is > what we should we do. However, for the landing page we should definitely be > auto-focused on the search box. I guess it is not easy to distinguish which > is which now, but we should be able to hack that. I agree, there is not much use for the arrow key navigation on the landing page before a query has been executed either via SAYT or by hitting enter. So, perhaps we can bring it back in those instances.
(In reply to comment #11) > (In reply to Nick Cameron [:nrc] from comment #10) > > (In reply to Schalk Neethling [:espressive] from comment #5) > > > (In reply to Georg Fritzsche [:gfritzsche] from comment #4) > > > > (In reply to Schalk Neethling [:espressive] from comment #3) > > > > > We actually specifically disabled this in the new UI. > > > > > > > > Hm, why? > > > > > > Here you go: > > > https://bugzilla.mozilla.org/show_bug.cgi?id=936199 > > > > I think that bug is for not auto-focusing on indexed pages, which I agree is > > what we should we do. However, for the landing page we should definitely be > > auto-focused on the search box. I guess it is not easy to distinguish which > > is which now, but we should be able to hack that. > > I agree, there is not much use for the arrow key navigation on the landing page > before a query has been executed either via SAYT or by hitting enter. So, > perhaps we can bring it back in those instances. Yep that makes perfect sense.
Wow, take a holiday, and people really go to town. :-) I saw the subject line during the day and thought "I'll ask Ehsan to wait for a few more people to weigh in". Lucky for me, it seems a small but forceful consensus has already emerged. I'm loath to make certain pages autofocus and other pages not (since, as Nick observes, they all look pretty much the same). If no one has a better idea, I'm inclined to just take Ehsan's patch that turns autofocus on all the time. If not being able to page-down once you reach a line number anchor (as with a direct result) bothers others people as much as it does me, we can put in the effort to special-case that. Before we do that, though, I want to know what Nick meant by "indexed pages": file views?
Flags: needinfo?(ncameron)
abbeyj registered in IRC that he finds autofocusing to interfere with doing type-to-select searches on file-view pages.
And Nick did mean "file views".
Alright, we just did a bunch of hashing things around in #static. How's this strike everyone? We auto-focus only on the front page (of every tree) and nowhere else. That way, when you surf to DXR via typing "d-x-return" or whatever, you're all set up to do a search, which is (we guess, informed by your personal experiences) the most common action. But once you start browsing around the tree, we assume you're likely to keep browsing (or otherwise clicking on links), so we don't autofocus anywhere else: not on any non-root folder views nor on any file views. Sane/insane?
(In reply to Erik Rose [:erik][:erikrose] from comment #16) > Sane/insane? Sounds pretty good to me!
Commit pushed to master at https://github.com/mozilla/dxr https://github.com/mozilla/dxr/commit/b3a1cce5aa0f46e0f61602644c2153ab608e207e Autofocus the query field at the root of each tree (only). Fix bug 973588. Close #245. Add an instance for testing markup generation.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Let's try that and see how we like it. I tried it locally, and it was fine, except that clicking the linked tree name in "Results from tree 'such and such':" brought me back to the root and autofocused the field. That was a bit jarring, but I think this is an improvement.
(This will need a new build to take effect, so give it a few hours.)
Thanks, this makes sense to me.
Flags: needinfo?(ncameron)
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.