(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!) Here are some basic improvements that we should apply to the "Find in Page" UI: - Move to top of the UI, to match the design of Firefox 4 - Needs to be tab-specific, not global - Consolidate Quick Find and Find - Remove "/" shortcut, too easy to trigger in error in an app where slashes are important - Show count of how many instances are on the page - “bounce” the results and make sure they stand out on the page - highlight all occurrences of a search term - make the focused result be in the middle of the page - dismissable with Esc or by clicking outside, or by the Cmd-F toggle again - Match whole word option - We have available space on this bar, options are good!

Also: - close when you click outside it

I'd like to vote against "Needs to be tab-specific, not global" - Very often when I am using Find in page, it is to locate on the page the terms I just searched the web for, and I have to do this for many tabs in the same session. I'd be fine with it as an option, but I'd always set it to window specific (like it is now) Also, please mark this to depend on bug 14871

I frequently wish I could pick the string to find from a history list of recently-used search terms. The retyping is annoying, and so is having to move a hand from mouse to keyboard. It would be great if you could do it all with the mouse. A use case that would really benefit from this is searching for two strings in alternation, repeatedly.

(In reply to comment #2) > I'd like to vote against "Needs to be tab-specific, not global" - Very often > when I am using Find in page, it is to locate on the page the terms I just > searched the web for, and I have to do this for many tabs in the same session. That can be solved. For example, in a tab with no previous Find history, the most recently-used Find text should be used automatically. Also, spawned tabs should inherit the Find history from their parent. I have quite a number of other ideas for improving Find. I’ve made a list, together with an outline of the workflow these ideas would enable[1]. Here’s a list of some of these, together with relevant bug numbers: A. Improving the Find bar’s interaction: • Find should be tab-specific (already mentioned above). → Bug 248955. • Invoking a top-oriented Find should not shift the page down. → Bug 248715. – This is what Safari does. • Remove the Close button. When the page is focused, slide the Find bar out. – This makes the Find bar less modal. • Remove the ‘Highlight all’ button. Instead, highlight terms automatically when Find is open. When Find is closed, fade the highlighting out. – Another mode eliminated. • Automatically hide the Find bar after a short period (15 sec?). → Bug 325234. – This also makes Find less modal, as you needn’t worry about closing the bar. – Works great together with auto-highlighting. • Moving to the Next or Previous occurrence of a term should smoothly scroll the page to that spot, centred on the term. → Also covered in bug 171237. – Like what should be done for named anchors (bug 355229 and bug 279629). B. Improving Find’s text field: • Highlight all matches (already mentioned above). → Bug 342101. • Backspace in Find should work like Undo, scrolling the page back to where you were before you mistyped. → Bug 275469. – Suggested by Jef Raskin in The Humane Interface, §5–4[2]. • Find’s matching should ignore accents and diacritics unless the ‘Match case’ option is checked. → Bug 442070 and bug 202251. – This is probably better than Internet Explorer, which has three separate options like diacritic-matching, in addition to case-matching. • Find’s algorithm should be loose, matching terms rather than phrases. If quotation marks (") are used at the beginning, it should match for the phrase, though not perfectly (spacing and punctuation would still be ignored). If quotation marks are inserted at the end as well, the last term of the phrase should be matched as a whole word. → Bug 343118. – Similar to what Google does. – This makes the modal ‘Match case’ option needed far less often. – This also makes the ‘Match whole word’ suggestion unnecessary. – The next three suggestions depend on this one. • Rename ‘Match case’ to ‘Match exactly’. → Similar to bug 269442. • Highlighting should use a different colour for each term matched. – Like Google Cache. • A double-click on a search term should scroll the page to its next occurrence. – Similar both to Google Toolbar and to SearchWP[3]’s jump-to-word buttons. C. Integration with Search (this will be the most controversial): • Automatically add to Find the terms you just used on any search engine. → Bug 270310 and bug 264123. – Similar to SearchBox Sync[4], but universal and zero-configuration. • Automatically execute a Find after clicking on a search result online, and scroll to the first result. → Bug 240432. – This is especially useful when combined with most of the above suggestions. [1] http://wiki.mozilla.org/User:David_Regev/Firefox_Search,_Revamped [2] http://books.google.com/books?id=D39vjmLfO3kC&pg=PA125&dq=%22Backspace%22 [3] http://code.google.com/p/searchwp/ [4] http://code.google.com/p/searchboxsync/

This bug needs a UI specification, preferably expressed in phases (needed-to-ship vs. extra-credit) before we can find an owner for it.

See bug 557877 and bug 537013 and bug 478903

Quick search "/" already disappears when you switch tabs, but FindBar (Ctrl+F) does not yet. (In reply to comment #0) > - Remove "/" shortcut, too easy to trigger in error in an app where slashes are > important This was dogfood recently and seems to work now. I think this "/" shortcut was just fixed so it doesn't trigger FAYT while in a text box or something: see bug 570230, bug 568429 and bug 567306. Another bug 569342 - findbar should not be enabled for about:addons is being worked on yet bug 570760 is put focus inside addons search.

Opera 10.62, Safari 5.0.2, Iron 6.0.475, Firefox 4.0 b6pre.

I would really like the following features from Opera and Safari: - Page dimmed when searching - All matches highlighted automatically - Emphasis on current match This feature from Chrome would also be nice: - # of current match, # of total matches (the latter also displayed by IE and Safari) I would immensely hate these: - Tab-specific searching - Each match a unique color - The search bar disappearing on a timer or by clicking on the page

ditto all points of comment 9. (except I'd like to hear/see rational for the dimming.) chrome does most of these very nicely *today* - and I'm finding myself spending more time there. of the blockers, bug 171237 is the oldest, would require no UI changes, and I suggest is the most needed. (hard to believe it still lives)

We should have choices: tab-specific, window-specific, or session-specific (that is search in all windows). Page dimming is only bells and whistles. I don't need this personally.

It would also really help if Find wasn't completely useless for finding "CD" on a page that has dozens of mentions of "LCD". Like "whole words" or something...

the release drivers are not going to track feature requests.

(In reply to Gingerbread Man from comment #9) > I would immensely hate these: > - The search bar disappearing on a timer or by clicking on the page I find the current behavior very annoying, after performing a search I have to manually close the toolbar, being lazy, this results in the toolbar being open for the rest of the session, stealing vertical space on my screen. If I want to search again, I still need to go to Edit > Find / Fx Menu > Find or Ctrl + F to get the focus back to the Find in page field if not using the mouse. In this case the find in page toolbar reappears with previous search filled in. At least please add an option for an auto-close timer for keyboard users. Off topic, but the Sync error toolbar could also benefit from auto-close these days ;)

The whole "Find in Page" needs an overhaul in Firefox. It's just painful to use. Look at Google Chrome to see how "Find in Page" should work.

I agree with "heraldo" that the "Find Box" should close by itself at some point and NOT stay open until the user manually closes it. But part of the BIG problem here is the massive amount of vertical space that is consumed from Firefox's FIND BAR. Mozilla, would you please implement a less-space-hogging "Find Box"? Maybe something like Google Chrome implemented (i.e., a small box in the upper right corner). Here's a screenshot of how Chrome does it: http://i.imgur.com/vCiyj.png

Should depend on bug 257061

The find bar should appear and move the whole page down(instead of appear ON the page) to increase discoverability. Note: There's no check box for "Highlight all results" because the results should be automatically highlighted. Feedback is welcome :)

Love it. Love it. Love it! The only nit I can think of is that the unused space on on the left side gives it an "unbalanced" feel. It may not feel this way in actual use, however.

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #20) > Created attachment 590940 [details] > Find bar mock-up Welcome to the Firefox team! Thanks for creating a mockup. :) > The find bar should appear and move the whole page down(instead of appear ON > the page) to increase discoverability. Of what is this increasing the discoverability? The undesired visual effect of moving the whole page down is precisely why we didn't place the find bar at the top of the page for all these years. Have you discussed the history of this bug with Limi? Why is this preferable when the user probably doesn't need the "Find in page" UI to find a word at the top of the page? Even if the "Find in page" UI is being used to find a word at the top of the page, the contents of the find bar take up at most half the width of the viewport in most cases, so the find bar can easily be moved horizontally to avoid obscuring the highlighted result on the page.

The find box should be like Google Chrome does it: a small box that drops down from the upper right corner. A bar that takes up vertical space across the WHOLE screen (like Firefox does it presently) is unnecessary and is basically poor design. One of the things I keep running into with Firefox FIND is that when I search for something, the found result is literally hidden by the find bar. The only way to discover the found result is to close the find bar or to scroll the page down. Implementing Google Chrome's small find box (see a screenshot in my comment above) is the perfect solution. Just copy what Google Chrome did. Their implementation of FIND is perfect.

(In reply to Nick from comment #23) > Just copy what Google Chrome did. Their implementation of FIND is perfect. I do not think so. a.The small box covers the content. b.when I search a term which is under the small box, the small box is shifted. Prev↑Next↓ attow are also shifted, it makes problem in case of clicking them by mouse continuously,

(In reply to Nick from comment #23) > Just copy what Google Chrome did. Their implementation of FIND is perfect. Definitely not. Originality is not overrated.

(In reply to Nick from comment #23) > One of the things I keep running into with Firefox FIND is that when I > search for something, the found result is literally hidden by the find bar. > The only way to discover the found result is to close the find bar or to > scroll the page down. This problem should be fixed bug 171237 in Firefox 12 which centers the match on the page if it's not in the current view.

(In reply to Frank Yan (:fryn) from comment #22) Thanks! I started by working on some paper-cut bugs (like this one) to get familiar with the process. So feedback is welcome! :) I did talk to Limi about this. The reason of placing the find bar on top is that the user always read from top to bottom. After typing the keyword on find box on top of the page, they can move their focus down to look at the result. This flow feels more natural. Also, one big problem of find-in-page now is that a lot of user don't know it exists or how to use it. It's very hard for first time users to notice there is a find bar on bottom of the page. Currently the find bar flashes yellow three times when first opened in order to get user's attention, which I think is not a very elegant design. If the page move down a little when enable find bar, it helps first time users notice the bar. For expert users, it's not too annoying and it doesn't cover any content. (In reply to Nick from comment #23) @Nick The design of Chrome's find bar is simple indeed, but it doesn't give user much control.(e.g. match case or whole word only) And like @Alice0775 said, the find bar does cover the content and shifts when you search something underneath. (Try open wikipedia and search 'creat account' which is on the upper right corner) A find bar "hangs" on top of the page is not very visual appear as well. So we don't think chrome's find bar is perfect, and we will definitely not copy the design. :)

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #27) > If the page move down a little when > enable find bar, it helps first time users notice the bar. For expert users, > it's not too annoying and it doesn't cover any content. You can see how Opera has implemented this. Pushing down the page causes issues however if you want to have a timeout on / autohide of the find in page bar. When the page is pulled up again, the page movement might confuse the user while reading or clicking a page element when the pull-up occurs.

I agree, Google Chrome current find bar isn't perfect, but it's clearly the most appealing and useful bar on the market. I also agree that the new Firefox search bar should take less space horizontally, ala Chrome. There is a lot of wasted space on the current mockup, but still it's a good start.

I've made this in 30 seconds and with my awful skills, but I think we should investigate in that direction. I know it causes troubles because of the different sizes that the bar could take, but with the adequate animation it should work perfectly well.

(In reply to Zhenshuo Fang from comment #27) @Zhenshuo Fang I totally agree about "match case or whole word only." These are nice features to have and is the one thing about Chrome's Find-function that I do find myself occasionally missing. But only occasionally. Thanks for telling me how to test Chrome on the Wikipedia page. I see what you mean about how the "find bar obstruction problem" is solved by putting the find box at the bottom of the page = user can always scroll down to reveal content. One thing that does annoy me in Firefox is that the popup that appears when a user puts his cursor over a link (i'll call it the link-popup-display) changes to the right side of the monitor when the FIND bar is open. I always find myself looking to the lower left corner for the link-popup-display, even when the FIND bar is open. Why not put the link-popup-display on the usual left side when the FIND bar is open? I have no problem with the link-popup-display switching to the right side when a user places the cursor over a link in the lower left corner of the screen, this I intuitively respond to by looking to the right. But I don't understand the design to move the popup to the right just because the FIND bar is open. This I find a bit burdensome.

Considering the "obstruction problem" that having the find box at the top produces, keeping it at the bottom of the page seems like it might be the preferable idea after all.

I think, The item of contents should _not_ be hidden by UI of the browser. The layout of contents should _not_ be limited by UI of the browser. Even if the Find box put on the bottom corner, the Important matter at the bottom corner will be hidden by the Find box UI.

I forgot one important thing on my poor made illustration : to spare space number of matches should be directy inside the type box.

(In reply to Alice0775 White from comment #33) @Alice0775 White No Alice, I do not believe you are correct when you say, "Even if the Find box put on the bottom corner, the Important matter at the bottom corner will be hidden by the Find box UI." If the Find box is at the bottom corner of the screen and covers up "important matter" then the window becomes scrollable. So the user can always scroll down to view the content. You can test this by going to this website: http://en.wikipedia.org/wiki/Special:PasswordReset now shrink the window dimensions until the word "special pages" is in the lower left corner of the window BUT no scrolling is needed to view the whole page (i.e., no scrollbar appears along the right margin of the window. Now activate the FIND box. See how the scrollbar has now appeared allowing you to scroll down and view the "special pages" part of the word?

Since every one is stating their opinion i'll input my own as well. I agree with Alice0775, there is no guarantee there is nothing important at the bottom of the page. No matter how you look at it you are hiding page content, although you don't know how important it is. Wikipedia is not the only page on the internet. I don't know what the problem is with the current implementation - this is the only way you can be really sure nothing is missing and you can always scroll down to see the whole page. The only welcome change to me is repositioning the bar to the top, seems pretty logic. Instead of trying to minimize the find bar i think you should keep it this way and recycle the used space with additional features. And as another thing - copying chrome should the last of firefox's priorities - big thumbs up to everyone who agrees.

(In reply to PR0PHET from comment #36) > And as another thing - copying chrome should the last of firefox's > priorities - big thumbs up to everyone who agrees. It's not about copy, it's about inspiration. In fact since its first release three years ago Chrome has made a lot of improvements and in term of UI I think it's clearly the most simple, clear and appealing browser out there. Closing eyes on the concurrence is anti-productive and leads nowhere. When another browser do best than Firefox we should analyze how and make the same even better.

To clarify... taking hints from chrome is not wrong, what i want to say this is : (In reply to Nick from comment #23) > Just copy what Google Chrome did. Their implementation of FIND is perfect. 1. Just copying... really? 2. Who said it is perfect? Not saying it's bad mind you, but still how can you say it's perfect, you could also take a look at opera, which is (to me) much better than what chrome does. Taking hint's is good, solely copying not. To me opera has a better find implemented than chrome, but you shouldn't copy either - try estimating the pro's and the con's of both and maybe exploring something new. If you think you have to take a similar approach because it's good, please do so, but not without thinking it through.

Another interesting Chrome-feature : http://littlebigdetails.com/post/2974115624/chrome-marks-the-position-of-cmd-f-search

(In reply to Guillaume C. [:GE3K0S] from comment #39) > Another interesting Chrome-feature : > http://littlebigdetails.com/post/2974115624/chrome-marks-the-position-of-cmd- > f-search That's Bug 259640, already a dependency of this one.

Is there an ETA on when the firefox find-bar will "auto-hide" itself when the user navigates to a different webpage? I'm really looking forward to this feature :)

Australis mockup for find in page : http://people.mozilla.com/~shorlander/files/australis-design-specs/images/Australis-i01-DesignSpec-MainWindow-%28FindBar%29.jpg I don't if Zfang thoughts have been taken into account.

I'd like to take a look at the find bar a bit. I've implemented a couple changes here, but not sure where to go with it. What do people think?

Comment on attachment 631474 [details] Find bar minor changes Zhenshuo, what do you think of these changes?

I think it's been established it is unlikely that the Find bar will be put at the top because it hides content if the content appears at the top of the page. Whereas content is never hidden when bar is at the bottom. At this point, the two main things that Firefox Find bar needs to address is: 1) auto-hide the bar when user leaves the page 2) add display of frequency information about the Find term (e.g., "1 of 5" should display in Find bar somewhere) there are additional enhancements a la Google Chrome (e.g., make "Highlight All" the default setting), but the above two are the most pressing.

(In reply to Chris Lee (:cleer) from comment #44) Thanks Chris for taking a look at this! :D 1)The red glow looks nice! I'm not sure whether we have a consistent red we use in other parts of the browser or it's just platform default? but we should keep the red color consistent across browser. 2)I like moving "Find" into the text field. One suggestion is changing it to "Find in page" so it's more clear? Since you already started working on this, you might also want to take a look at the interaction since it needs more work than the visual (no pressure :P ) I agree w/ Nick, other than the three things he mentioned above, you can also work on "toggle find off by Ctrl+F" or the "match whole word" option.

The bar should clearly be on top for usability concerns, but also because a lot of websites have their own bar at the bottom and the find bar could be mingled with these. I personally would love to have a mix between Stephen Horlander (http://people.mozilla.com/~shorlander/files/australis-design-specs/images/Australis-i01-DesignSpec-MainWindow-%28FindBar%29.jpg) and Zhenshuo Fang (see attachments) mockups with Chris Lee's improvements.

I would like to mention that keys that "toggle" have a severely detrimental impact on usability. Without toggle, I can always "Ctrl+F + type" to find something. With toggle, I have to first check if it's already visible. Please keep this in mind when deciding this change.

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #47) > (In reply to Chris Lee (:cleer) from comment #44) > > Thanks Chris for taking a look at this! :D > > 1)The red glow looks nice! I'm not sure whether we have a consistent red we > use in other parts of the browser or it's just platform default? but we > should keep the red color consistent across browser. > > 2)I like moving "Find" into the text field. One suggestion is changing it to > "Find in page" so it's more clear? > > Since you already started working on this, you might also want to take a > look at the interaction since it needs more work than the visual (no > pressure :P ) > > I agree w/ Nick, other than the three things he mentioned above, you can > also work on "toggle find off by Ctrl+F" or the "match whole word" option. It would be helpful to work out more concrete decisions on both the visual and interaction side. Visual-wise, the most complete mockup we have is the Australis one from shorlander, but, in my opinion, there are some issues with it (some of these are much more minor than others, but throwing them in for discussion). (1) The buttons (some of which are actions and some of which are toggles) all look like plain text, which makes them not very discoverable. (2) I think we wanted icons at least instead of next/previous. (3) It make more sense to have next/previous in the opposite order. Not sure which one is more intuitive/preferable, though. (4) This might be an illusion because it's thinner, but it looks to me like the search box is unusually sharply cornered. That seems a bit odd to me, especially considering that the theme of Australis is to make things round and friendly. I think the same roundness as the current Firefox location bar would be appropriate. (5) I'm not sure about this one, but I feel like the background of the bar doesn't match well with the rest of the UI. (6) Do we have mockups for other OSes? Interaction-wise, there are obviously some disagreements about questions like (1) Should the bar be at the top or bottom of the browser? (2) Should be tab-specific, page-specific, or global? (3) Should the keyboard shortcut toggle it or just make it visible? I think there are valid points on each side for all of these questions.

Also, Zhenshuo, what was the reasoning behind right-aligning the elements? One minor thing to keep in mind is that other, similar bars like the dev tools bottom bar are left-aligned.

(In reply to Chris Lee (:cleer) from comment #50) > Visual-wise, the most complete mockup we have is the Australis one from > shorlander, but, in my opinion, there are some issues with it (some of these > are much more minor than others, but throwing them in for discussion). I wouldn't read too much into that mockup. It isn't final which is why I didn't post it here. > (1) The buttons (some of which are actions and some of which are toggles) > all look like plain text, which makes them not very discoverable. We are moving most of our toolbar buttons to borderless so we should be consistent here. > (2) I think we wanted icons at least instead of next/previous. Works for me. > (3) It make more sense to have next/previous in the opposite order. Not sure > which one is more intuitive/preferable, though. I think we should flip them also. > (4) This might be an illusion because it's thinner, but it looks to me like > the search box is unusually sharply cornered. That seems a bit odd to me, > especially considering that the theme of Australis is to make things round > and friendly. I think the same roundness as the current Firefox location bar > would be appropriate. Not sure about the mockup but it should have a consistent radius with the rest of the new theme. > (5) I'm not sure about this one, but I feel like the background of the bar > doesn't match well with the rest of the UI. Was playing around with overlaying it partially transparent. Probably not what we should go with. > (6) Do we have mockups for other OSes? No. > Interaction-wise, there are obviously some disagreements about questions > like > > (1) Should the bar be at the top or bottom of the browser? It should be at the top where almost all of the rest of our UI lives. The only reason it is at the bottom is because of technical constraints with reflowing content if I remember correctly? > (2) Should be tab-specific, page-specific, or global? I think the UI should be tab-specific but we should carry the search term in case you want to search multiple tabs.

(In reply to Stephen Horlander from comment #52) > (In reply to Chris Lee (:cleer) from comment #50) > > (1) Should the bar be at the top or bottom of the browser? > > It should be at the top where almost all of the rest of our UI lives. The > only reason it is at the bottom is because of technical constraints with > reflowing content if I remember correctly? I agree all UI at the bottom should be killed for usability concerns. In fact the solution would be to push the page content down when the search bar is triggered (Opera already does it).

<<<3) Should the keyboard shortcut toggle it or just make it visible?>>> Toggle is really bad idea. This is what should happen for best usability: 1) if the find-bar is hidden and the user presses Ctrl+F = find-bar should appear and display (and highlight) the previously typed entry (if any) 2) when user navigates to a new page = the find-bar should auto-hide itself 3) if find-bar is hidden and user presses F3 = firefox should "find" the previously typed entry. That is, user presses Ctrl+F on webpage-A and performs a search of the page. User then navigates to webpage-B (causing Find-Bar to hide) and user presses F3 to perform the same search on webpage-B. 4) if find-bar is visible and user types Ctrl+F = focus should be placed onto the Find-bar and the previously typed entry should be highlighted. That is, there should be no toggle.

(In reply to Chris Lee (:cleer) from comment #51) > Also, Zhenshuo, what was the reasoning behind right-aligning the elements? > One minor thing to keep in mind is that other, similar bars like the dev > tools bottom bar are left-aligned. No there's no particular reason for that. The alignment should be consistent w/ other bars. And things like the position of the close button should be consistent w/ the platform. (In reply to Chris Lee (:cleer) from comment #50) > > (2) I think we wanted icons at least instead of next/previous. > (3) It make more sense to have next/previous in the opposite order. Not sure > which one is more intuitive/preferable, though. Agree w/ icons. And if they are icons, the order should be previous/next, otherwise it's confusing. We can either do left-right "< >" or up-down "^ v". Personally up-down makes more sense to me. > Interaction-wise, there are obviously some disagreements about questions > like > > (1) Should the bar be at the top or bottom of the browser? I think it should be on top. reason explained on comment 27. Plus it's close to the rest of the UI. > (2) Should be tab-specific, page-specific, or global? It shouldn't be global. Between tab and page-specific, if we decided to do find bar on top and push the content down, we should minimize the interaction of activating the find bar. so tab-specific might be better. > (3) Should the keyboard shortcut toggle it or just make it visible? I can see shortcut is a way to refocus the find bar without clicking w/ mouse. If we move the bar on top, keep the interaction as it is now works for me. If we can't move the bar on top because of technical constrains, then we should provide a quick way to kill the bar and toggle is one way to do it. Also, we should definitely implement highlight all by default and match whole word.

Okay, if the find bar will go at the top, how should it be positioned relative to other things at the top, like the web console or other dev tools?

(In reply to Chris Lee (:cleer) from comment #56) > Okay, if the find bar will go at the top, how should it be positioned > relative to other things at the top, like the web console or other dev tools? I think directly under the navbar or the bookmarks bar if present. The devtools cover the page content or are directly related to it.

Looks like work has already been done on the auto-"highlight all" front here: https://bugzilla.mozilla.org/show_bug.cgi?id=342101 ...but it's blocked by the fact that "highlight all" for small queries might with many results might be very slow? https://bugzilla.mozilla.org/show_bug.cgi?id=251862 Can someone confirm whether that's still a problem?

(In reply to Chris Lee (:cleer) from comment #58) > Looks like work has already been done on the auto-"highlight all" front > here: https://bugzilla.mozilla.org/show_bug.cgi?id=342101 > > ...but it's blocked by the fact that "highlight all" for small queries might > with many results might be very slow? > https://bugzilla.mozilla.org/show_bug.cgi?id=251862 Can someone confirm > whether that's still a problem? Yes, it's still a problem, partially because we use an enumerator that isn't optimized.

(In reply to Chris Lee (:cleer) from comment #58) > Can someone confirm whether that's still a problem? It is still a problem: Load https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js, turn on highlight all then type "a" and notice the browser become unresponsive for a bit.

Thoughts?

Comment on attachment 632966 [details] Screenshot Why did you make the text box square? On OS X, text boxes for searching always have rounded endcaps.

(In reply to Frank Yan (:fryn) from comment #63) > Comment on attachment 632966 [details] > Screenshot > > Why did you make the text box square? > On OS X, text boxes for searching always have rounded endcaps. I thought more squarish search boxes might be a design decision for Australis (mostly off of the mockup above before realizing that it's probably Windows-specific). I take it that the decision is more to leave them rounded on Mac, then? I'll change it to rounded.

Comment on attachment 632966 [details] Screenshot Having "Previous" on the left and "Next" on the right is a major improvement. :)

(In reply to Chris Lee (:cleer) from comment #64) > I thought more squarish search boxes might be a design decision for > Australis (mostly off of the mockup above before realizing that it's > probably Windows-specific). I take it that the decision is more to leave > them rounded on Mac, then? I'll change it to rounded. Yeah, Stephen's mockup ( http://people.mozilla.com/~shorlander/files/australis-design-specs/images/Australis-i01-DesignSpec-MainWindow-%28FindBar%29.jpg ) is for Windows. (In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #47) > "toggle find off by Ctrl+F" We shouldn't change ctrl/cmd+f to toggle the find bar. That would break internal consistency with ctrl/cmd+l (location bar) and ctrl/cmd+k (search bar) and eternal consistency with just about every other application that has a find bar. Esc (which we've already implemented) is the de facto standard shortcut for dismissing the find bar. Instead, to fix the problem of the find bar staying open, we should have the find bar's state be per-tab, so when you switch from tab A to tab B, if you didn't have the find bar open previously in tab B, the find bar closes.

(In reply to Frank Yan (:fryn) from comment #65) > Comment on attachment 632966 [details] > Screenshot > > Having "Previous" on the left and "Next" on the right is a major > improvement. :) Assuming that we all remember that they need to be reversed for RTL. :-)

An option to search across tabs would also be nice, but would require a lot of work. (In reply to Chris Lee (:cleer) from comment #62) > Created attachment 632966 [details] > Screenshot Very nice. Just note that the close button should be on the right on windows and the corners rounded on OSX (as mentioned above) for OS consistency.

Work in progress patch with following changes: - switched previous/next spacing - icons instead of text for previous/next - restyle buttons to look like plain text as specced by Australis - restyle search bar like top-level search bar - attach find bar to top of browser instead of bottom (only for Mac OS X, tested on 10.7 Lion)

(In reply to Chris Lee (:cleer) from comment #70) > Created attachment 633249 [details] > Screenshot of patch You probably already noticed, but it's missing the match case checkbox, and when phrase is not found the search box should glow red. One other thing is we probably want to change the phrase "phrase not found" and move it into the end of the search box or at least near the search box so that we can add counting in the future, something like "2/10 matches". But for now we can just make the search box wider.

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #71) > (In reply to Chris Lee (:cleer) from comment #70) > > Created attachment 633249 [details] > > Screenshot of patch > > You probably already noticed, but it's missing the match case checkbox, and > when phrase is not found the search box should glow red. > > One other thing is we probably want to change the phrase "phrase not found" > and move it into the end of the search box or at least near the search box > so that we can add counting in the future, something like "2/10 matches". > But for now we can just make the search box wider. As explained above, I'm guessing that the Australis design spec is to not have checkboxes (going off shorlander's Windows mockup, unless WIndows is just going to be incredibly different). I'm second guessing the red glow - do we really want to do that? It personally feels a bit intrusive to me; I think "phrase not found" is sufficient. If we discuss the pros and cons and decide it's a good idea, though, I'll re-add it. If so, we need to lock down the right color of red. About moving "phrase not found"/# matches (eventually) - do you mean putting the status text in the search box like Chrome? Thanks for the feedback! :)

(In reply to Frank Yan (:fryn) from comment #66) > We shouldn't change ctrl/cmd+f to toggle the find bar. That would break > internal consistency with ctrl/cmd+l (location bar) and ctrl/cmd+k (search > bar) and eternal consistency with just about every other application that > has a find bar. > > Esc (which we've already implemented) is the de facto standard shortcut for > dismissing the find bar. > > Instead, to fix the problem of the find bar staying open, we should have the > find bar's state be per-tab, so when you switch from tab A to tab B, if you > didn't have the find bar open previously in tab B, the find bar closes. Esc only works when the find bar is in focus. But yes, I agree with tab-specific behavior and keep crtl+F the way it is now.

Also, regarding highlight all and match case (and whole word is that ends up being implemented and included): I suppose these are confusing because they look like plain text but are toggle buttons. I think we should use icons along with the text to make it clearer that they're clickable.

In reply to Chris Lee (:cleer) from comment #72) > As explained above, I'm guessing that the Australis design spec is to not > have checkboxes (going off shorlander's Windows mockup, unless WIndows is > just going to be incredibly different). ah I see...the un-check mode got me confused. (wonder whether it will confuse other users) > I'm second guessing the red glow - do we really want to do that? It > personally feels a bit intrusive to me; I think "phrase not found" is > sufficient. If we discuss the pros and cons and decide it's a good idea, > though, I'll re-add it. If so, we need to lock down the right color of red. > > About moving "phrase not found"/# matches (eventually) - do you mean putting > the status text in the search box like Chrome? "phase not found" now is too far away from the search box, uses won't notice it so we kind of need the glow. But if we move the "not found" message closer to the user's focus, which is the search box, we probably don't need the glow. So I feel like among these two we need to at least have one. (In reply to Chris Lee (:cleer) from comment #74) > Also, regarding highlight all and match case (and whole word is that ends up > being implemented and included): I suppose these are confusing because they > look like plain text but are toggle buttons. I think we should use icons > along with the text to make it clearer that they're clickable. yes...I was a bit confused. We should definitely make it more clear, not sure using icons is a good idea though. Summon shorlander on visual design :D

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #75) > In reply to Chris Lee (:cleer) from comment #72) > "phase not found" now is too far away from the search box, uses won't notice > it so we kind of need the glow. > But if we move the "not found" message closer to the user's focus, which is > the search box, we probably don't need the glow. So I feel like among these > two we need to at least have one. I'll try moving the status message around. On another note, were there any decisions made about the discussion far above about a small, partial-wide search bar like Chrome's? I agree with users who said that it's an elegant solution that might be worth exploring. There are perhaps some minor problems in Chrome's implementation with it overlapping things on the page and moving around, but they seems pretty minor. Has user research been done on whether options like case sensitivity are actually frequently used/necessary? I would guess not.

(In reply to Chris Lee (:cleer) from comment #76) > > On another note, were there any decisions made about the discussion far > above about a small, partial-wide search bar like Chrome's? I agree with > users who said that it's an elegant solution that might be worth exploring. > There are perhaps some minor problems in Chrome's implementation with it > overlapping things on the page and moving around, but they seems pretty > minor. > No I don't think any decisions were made, we can always explore and test it out. The problem of overlapping is kind of minor cause generally you don't search something under the find bar, but when you do, it's really annoying. > Has user research been done on whether options like case sensitivity are > actually frequently used/necessary? I would guess not. Not that I know of. The match case is probably not used that often. But it's quite useful when you want to search abbreviations.

Quick mockup (ignore spacing issues) of another option for buttons. Obviously not consistent with other UI elements, but just a thought.

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #77) > Not that I know of. The match case is probably not used that often. But it's > quite useful when you want to search abbreviations. There was a lot of discussion about adding "match whole words", and IIRC the agreement was that case sensitivity is probably used less than that, but without specific studies. There was also talk of these features being considered cluttery, and "match case" being there for historic reasons rather than because it's considered necessary. Having said that, "match whole words" would be a godsend; current search can be utterly useless for short words in long documents. Note that it can also be used for matching most abbreviations, because they rarely collide with real words.

So maybe we could get rid of "match case" (and make "highlight all" default and get rid of that button if the memory issue gets fixed up) and try to get "match whole words" implemented. Removing "match case" should be backed up with data if done, though.

Adding an animation to the find bar would be nice to indicate to the user that it has appeared and to make the page content go down in a smoother way (however this should be resolved by adding animation to all the toolbars).

Latest screenshot. Thoughts?

(In reply to Chris Lee (:cleer) from comment #82) > Created attachment 633695 [details] > Screenshot > > Latest screenshot. Thoughts? Look very good IMO, however as you mentioned it before to test a partial-wide bar would be a good idea (with the number of results directly into the search box à la Chrome for example).

(In reply to Chris Lee (:cleer) from comment #82) > Created attachment 633695 [details] > Screenshot > > Latest screenshot. Thoughts? Why even have a "Highlight All"? Just make it default. What use cases exist where turning off Highlight All achieves anything? I'm looking at how other Find/Search software works like in Ubuntu, Chrome, etc and Highlight All is the default for all search outputs. I can't think of a reason for turning it off. Nothing is accomplished by turning it off. On/Off, user still finds what he/she looking for. So I say simplify the code and just make Highlight All the default with no on/off switch. But if there's a good reason for being able to turn it off, please do mention it.

I think just performance problem if highlight all default. STR 1. Turn highlight all on 2. Open http://www.w3.org/TR/html5/single-page.html 3. Open FindBar 4. Type "tag" without quotation marks Actual Result: Browser try to highlight "t" when I type t, and then browser stop to response

Can't reproduce it on latest Nightly x64 on Win7 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:16.0) Gecko/16.0 Firefox/16.0a1 nothing hangs when searching with highlight, the only hang I feel is when I load site I also think that highlight all should be a default setting like in other browsers. If performance is the problem, time to fix it ;)

(In reply to Virtual_ManPL from comment #86) > Can't reproduce it on latest Nightly x64 on Win7 > Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:16.0) Gecko/16.0 Firefox/16.0a1 > nothing hangs when searching with highlight, Your typing speed might be faster than me. Please try little bit slowly to type.

There is indeed lag. But I too feel, now would be the best opportunity to fix the problem as highlight should be on by default.

Yes, there are apparently performance problems impeding us from making "highlight all" default. That's https://bugzilla.mozilla.org/show_bug.cgi?id=251862 , if you'd care to fix it.

Latest patch for OS X, based off of shorlander's new mockup https://www.dropbox.com/s/ijg3cmw00z4ej19/Australis-i02-DesignSpec-MainWindow-(FindBar).psd

Is there a new mockup for Windows ?

Just a thought: how about using more natural language for the placeholder instead of just "Find" or "Find in page"? For reference, our location bar says "GO to a Website" (confused by the capitalization there...) I think it might make be appropriate for the find bar to say "Find a phrase on this page" or something similar.

(In reply to Chris Lee (:cleer) from comment #93) > might make be appropriate for the find bar to say "Find a phrase on this > page" or something similar. That's going to be too long in various languages.

(In reply to Dão Gottwald [:dao] from comment #94) > (In reply to Chris Lee (:cleer) from comment #93) > > might make be appropriate for the find bar to say "Find a phrase on this > > page" or something similar. > > That's going to be too long in various languages. Which? There's no reason the find text field couldn't be larger at normal window size.

Progress update here: I'm ready to work on Windows; waiting on mockup(s) from Stephen. Have done some minor work on it based off of the Mac and early Windows mockups. Waiting on review for Mac OS X patch.

Comment on attachment 635543 [details] [diff] [review] Patch for find bar on Mac OS X (tested on 10.7 Lion) Review of attachment 635543 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for working on this! ::: toolkit/content/widgets/findbar.xml @@ +183,5 @@ > tooltiptext="&findCloseButton.tooltip;" > oncommand="close();"/> > + <xul:textbox anonid="findbar-textbox" > + class="findbar-textbox findbar-find-fast" > + xbl:inherits="flash" /> Nit: You don't need a space before the slash, since this is XML, not XHTML that needs to be backwards-compatible with '90s browsers. (Not a big deal.) Why were the "#ifdef MOZ_WIDGET_GTK" lines removed? Do you know why they were there before? @@ +914,5 @@ > <parameter name="aHighlight"/> > <parameter name="aWord"/> > <parameter name="aWindow"/> > <body><![CDATA[ > + aHighlight = true; I don't think this is right... ::: toolkit/locales/en-US/chrome/global/findbar.dtd @@ +17,3 @@ > <!ENTITY highlight.accesskey "a"> > <!ENTITY highlight.tooltiptext "Highlight all occurrences of the phrase"> > +<!ENTITY caseSensitiveCheckbox.label "Match Case"> I guess these entity names don't really need to be updated. ::: toolkit/themes/pinstripe/global/findBar.css @@ +63,5 @@ > + padding: 2px 6px; > +} > + > +.findbar-find-next:active, > +.findbar-find-previous:active, Why are the :active states of next/previous matching the checked states of highlight/case but different from the :active states of highlight/case? This is inconsistent.

First I un-bitrotted the patch of Chris Lee, fixed it up on Windows first and after that on OSX. OSX needed most of the work, but it ended up looking quite ok. One thing is still nagging me: the searchbox' top border is aligned 1px lower than the top border of the previous/ next buttons. Does anyone know how to properly fix that?

This is a tracking bug for all find bar improvements : you should post your patch in bug 776708 because it concerns its appearance. Do you use this mockup : http://people.mozilla.com/~shorlander/files/australis-design-specs/images/Australis-i01-DesignSpec-MainWindow-%28FindBar%29.jpg because IIRC it's outdated.

I think I should mention, my add-on FindBar Tweak (https://addons.mozilla.org/en-US/firefox/addon/findbar-tweak/) already addresses many of the issues raised in this bug, giving complete control to the user about what options should be enabled or not. Doing a very quick read-through, many of the changes and fixes proposed involve making the new behavior mandatory for all users and I'm not sure that's the way to go here because some things are very "user preference specific" for lack of a better term. Let me know if you think FBT is also relevant in other bugs please.

(In reply to Quicksaver from comment #100) > I think I should mention, my add-on FindBar Tweak > (https://addons.mozilla.org/en-US/firefox/addon/findbar-tweak/) already > addresses many of the issues raised in this bug, giving complete control to > the user about what options should be enabled or not. Doing a very quick > read-through, many of the changes and fixes proposed involve making the new > behavior mandatory for all users and I'm not sure that's the way to go here > because some things are very "user preference specific" for lack of a better > term. > > Let me know if you think FBT is also relevant in other bugs please. Wow this add-on is now a must have until the Find bar gets some proper improvements/upgrades.

Hi, I'm working on the Automation team with Mozmill and we have a test which uses the findBar. This week we've fixed it 3 times due to the latest changes and we were wondering if the next ones will be separate or in a single patch. We need this information in order to see how to proceed with our test to avoid failures. It would help us a lot if all the changes will be done in a single commit. Please let us know if this is possible.

Batching patches makes regression hunting harder, so we're not going to do that, but as far as I know there aren't any other fundamental changes to the find bar planned either. Frankly, the XPath style look-ups in Mozmill tests are kind of embarrassing. In order to avoid test failures that aren't due to the UI actually being broken, I'd recommend making those tests less fragile.

(In reply to Dão Gottwald [:dao] from comment #103) > Batching patches makes regression hunting harder, so we're not going to do > that, but as far as I know there aren't any other fundamental changes to the > find bar planned either. Frankly, the XPath style look-ups in Mozmill tests > are kind of embarrassing. In order to avoid test failures that aren't due to > the UI actually being broken, I'd recommend making those tests less fragile. Thanks Dao! And yes, we are aware of that and currently changing those element getters. This work is done by a contributor, and his work bitrotted twice lately due to the ui changes. So if no other fundamental changes will come, we might be able to finish the patch soon.

Was "Highlight All" left out of the mockups on error or intentionally? As a heavy user of it, I hope it is retained.

Will "Highlight All" save its state after restarting the browser?

Please don't remove the "CTRL + /" shortcut as it's stated in the Features/Release tracking page. I use it a lot to toggle the status bar. Add-ons like InFormEnter doesn't not provide other solution than a drop down menu located on the status bar. Selecting the properly form information takes a lot of steps without the shortcut.

I wanted to propose to add 'depends on bug 340814'.

FINALLY the "match whole word" is getting implemented(hopefully!) After seeing multiple bug report about that getting closed with the answer *working as designed* or *get an extension to do it* by firefox devs, it's nice to see one dev tackling it. Only took 5 years or so *sigh*

I think the fact that this bug has "Find in page" in its summary and that it's also a "Toolkit :: Find Toolbar" bug might lead to some confusion. As such, the purpose of this tracking bug should be clarified. While toolkit changes that would also affect firefox's "Find in page" bar would be appropriate here, other specific changes to the toolkit's find bar that wouldn't affect Firefox should not. For example, IMO bug 998343 shouldn't block this, as "Find in page" (and all of the discussion here, unless I missed something?) is relative to firefox only, while bug 998343 is not (Firefox has no "Replace" anywhere as far as I know). On the other hand, if this tracking bug would track everything-toolkit-findbar, then its summary should be changed. I'm not doing any of this myself because I don't know what's the better choice here, but definitely one or the other would be good for clarification and organization.

(In reply to Luís Miguel [:Quicksaver] from comment #110) > I think the fact that this bug has "Find in page" in its summary and that > it's also a "Toolkit :: Find Toolbar" bug might lead to some confusion. As > such, the purpose of this tracking bug should be clarified. > > While toolkit changes that would also affect firefox's "Find in page" bar > would be appropriate here, other specific changes to the toolkit's find bar > that wouldn't affect Firefox should not. I think *all* changes to toolkit's find bar will affect FF because that's what's under the hood (see Bug 14871 Comment 60). So practically, when FF wants to change find bar, they just do their changes in toolkit, and all other consumers will automatically get the same changes (e.g. Thunderbird, see screenshots in Bug 530629). While this is a bit FF-centric, under the assumption that FF gets it right somehow, this has the advantage of find bar being consistent across Mozilla products. So imo the distinction comment 110 is trying to make doesn't exist and wouldn't help much. > For example, IMO bug 998343 shouldn't block this, as "Find in page" (and all > of the discussion here, unless I missed something?) is relative to firefox > only, while bug 998343 is not (Firefox has no "Replace" anywhere as far as I > know). Dito. All other consumers of find bar are affected (ideally benefitting) from changes made in toolkit's findbar on behalf of FF. So when TB wants to add an inline Replace bar on top of toolkit's Findbar for their composition window, that depends on all the changes of toolkit's find bar. That's why TB's "inline replace" Bug 998343 *depends* on this bug 565552 (i.e. this bug 565552 blocks bug 998343, and not the other way round as comment 110 wrongly suggests) > On the other hand, if this tracking bug would track > everything-toolkit-findbar, then its summary should be changed. > > I'm not doing any of this myself because I don't know what's the better > choice here, but definitely one or the other would be good for clarification > and organization. Indeed, the summary should probably be more toolkit-oriented. Given that FF is the biggest consumer, I think it's fair and useful for bugzilla searches if we keep their name of the feature in the summary, perhaps something like this: "Find toolbar ("Find in page") improvements and ideas tracker" Then, in whiteboard, include a reference to a comment defining the purpose of this bug, probably something along comment 99: > This is a tracking bug for all find bar improvements. Please add any bugs/RFE's in the "Depends on" field of this bug if they suggest/implement improvements to find bar (aka "Find in page" in FF). This tracking bug focuses on find bar UX (as opposed to purely technical bugs in the backend). Note that technically, most of the find bar code lives in toolkit, so it's shared between Mozilla products like Firefox and Thunderbird. (In reply to Luís Miguel [:Quicksaver] from comment #100) > I think I should mention, my add-on FindBar Tweak > (https://addons.mozilla.org/en-US/firefox/addon/findbar-tweak/) already > addresses many of the issues raised in this bug, giving complete control to > the user about what options should be enabled or not. Doing a very quick > read-through, many of the changes and fixes proposed involve making the new > behavior mandatory for all users and I'm not sure that's the way to go here > because some things are very "user preference specific" for lack of a better > term. It's great to see addons showcasing improvements that should/could be considered to go into core, and I generally agree with :Quicksaver's caveat that "one-for-all" approaches should be used in a very careful and considerate way, seeking to allow flexibility for different users and scenarios (and, as I would add, avoiding over-simplification of the UI to the extent of losing essential versatility and functionality, under the pretext of UX-minimalism)...

(In reply to Thomas D. from comment #111) > All other consumers of find bar are affected (ideally benefitting) > from changes made in toolkit's findbar on behalf of FF. So when TB wants to > add an inline Replace bar on top of toolkit's Findbar for their composition > window, that depends on all the changes of toolkit's find bar. That's why > TB's "inline replace" Bug 998343 *depends* on this bug 565552 (i.e. this bug > 565552 blocks bug 998343, and not the other way round as comment 110 wrongly > suggests) You're absolutely right, I had read that backwards, I'm sorry about that.

adding bug 340814 to the list? anyone?

(In reply to albert from comment #113) > adding bug 340814 to the list? anyone? That's not necessary as it's in the right component and it doesn't relate to comment 0 although I think the scope of this bug is not well defined to be honest. I will nominate bug 340814 for the backlog of higher priority bugs for you though.

(In reply to Matthew N. [:MattN] from comment #114) > (In reply to albert from comment #113) > > adding bug 340814 to the list? anyone? > > That's not necessary as it's in the right component and it doesn't relate to > comment 0 Sure. > I will nominate bug 340814 for the backlog of higher priority bugs > for you though. Great. Thanks!