Move the find toolbar to be displayed on the top of the page instead of the bottom, which is its current position. Also, the find toolbar should move to the top of the view-source page(s), for the sake of consistency.

Comment on attachment 746502 [details] [diff] [review] Move findbar to the top Review of attachment 746502 [details] [diff] [review]: ----------------------------------------------------------------- The animation is pretty rough for me (on OS X). I think we need to override the default transitions on findbar too. I don't care if the `findbar { }` styles in toolkit/themes/.../global/findBar.css suck. I just want the findbar in browser.xul to look good and work well. Plus, we need to transition `margin-top`. I also suggest changing the timing functions to what I recommended in bug 867317 comment 5. ::: browser/themes/linux/browser.css @@ +2314,5 @@ > background: url("chrome://browser/skin/privatebrowsing-mask.png") center no-repeat; > width: 40px; > } > + > +#appcontent > findbar { This can simply be #FindToolbar, I think, since only browser.xul uses browser.css, if I recall correctly. ::: toolkit/themes/linux/mozapps/viewsource/viewsource.css @@ +120,5 @@ > #aboutName { > list-style-image: url("moz-icon://stock/gtk-about?size=menu"); > } > + > +#appcontent > findbar { This can also be #FindToolbar, I think.

And, as always, thank you for working on this! :)

I think we should introduce some attribute to indicate that the find bar is above the content and let toolkit/themes/*/global/findBar.css handle it. Mike, can you update your patch?

Excellent suggestion, Dão, to introduce the attribute. Makes for a lot cleaner implementation!

Comment on attachment 773477 [details] [diff] [review] Move findbar to the top >--- a/toolkit/themes/linux/global/findBar.css >+++ b/toolkit/themes/linux/global/findBar.css >+findbar[position="top"] { >+ padding-bottom: 4px; >+ padding-top: 2px; This makes the padding unbalanced. I don't think you need to adjust it at all, i.e. just drop these two properties. >+ border-top: none; nite: border-top-style: none; >+ border-bottom: 2px solid; >+ -moz-border-bottom-colors: ThreeDHighlight ThreeDShadow; The white highlight border at the bottom looks unintended and seems unnecessary. Just use this: border-bottom: 1px solid ThreeDShadow; r+ with these changes

(In reply to Dão Gottwald [:dao] from comment #7) > nite: border-top-style: none; nit :)

Adjusted Linux styles as per Dão's suggestion. NOTE: I only had to change the order of the border colors to have the white color be the inner color, instead of the outer one. This looks very nice to me and achieves parity with the previous implementation (on-bottom). Carrying over r=dao.

Adjusted border on Linux, after IRC talk with Dão. Carrying over r=dao.

Mozilla changed mind :( See Bug 97023 Comment#12 > If we will position to top of the content, the content is shaked by the > toolbar visible changed. > > See Asa's comment > http://weblogs.mozillazine.org/asa/archives/2005/09/ > berkun_switches_to_firefox.html > > His first criticism is of the Find toolbar's location, at the bottom of the app rather than the top. We tried both configurations and the bottom was the solution that didn't cause the content area to shift down a couple of lines. This seemed much less jarring. We haven't done any serious usability testing on this but we've been following the feedback quite closely and Scott's not alone in this concern.

(In reply to Mike de Boer [:mikedeboer] from comment #10) > Created attachment 773881 [details] [diff] [review] > Move findbar to the top > > Adjusted border on Linux, after IRC talk with Dão. > > Carrying over r=dao. A similar adjustment is needed on windows, background-image property of find bar adds a pseudo-border on top, it should be inverted now and on the bottom. Should I open a new bug for this?

(In reply to Quicksaver from comment #14) > > A similar adjustment is needed on windows, background-image property of find > bar adds a pseudo-border on top, it should be inverted now and on the > bottom. Should I open a new bug for this? Yes please! Could you add a screenshot and CC me?

There needs to be a pref added to optionally put it at top or bottom. The 'jarring' shove down of the page on open of the Find-bar is distracting and annoying. Especially during/using the 'quick-find'

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #16) > There needs to be a pref added to optionally put it at top or bottom. The > 'jarring' shove down of the page on open of the Find-bar is distracting and > annoying. Especially during/using the 'quick-find' That sounds reasonable. Could you create a bug for that and CC me?

(In reply to Mike de Boer [:mikedeboer] from comment #17) > (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #16) > > There needs to be a pref added to optionally put it at top or bottom. The > > 'jarring' shove down of the page on open of the Find-bar is distracting and > > annoying. Especially during/using the 'quick-find' > > That sounds reasonable. Could you create a bug for that and CC me? https://bugzilla.mozilla.org/show_bug.cgi?id=893013

This is an odd UI change, and I don't see reasoning for it. https://bugzilla.mozilla.org/show_bug.cgi?id=97023#c12 is still valid.

While testing for the pre-beta sign-off of the Find Bar Redesign feature, I tried to verify this bug with the latest Aurora (build ID: 20130902004002), and this works as expected on Win 8 32bit and Ubuntu 12.10 32bit. The findbar appears now at the top of the webpage.

Setting relnote flag for whenever this sticks (26 or later due to bug 914180).

Dolske - can you provide final assessment of whether this is ready to move up to Aurora with FF26? It looks like bug 893446 is fixed and bug 914180 didn't get backed out on central - was that the only remaining blocker?

A better question for Mike, but AIUI the plan was to back it out on 25 (done), and then reassess what the plan for this feature is. So it's expected to be on 26 for now.

Mike - are there any remaining blockers or a chance this will not ship that you are aware of?

Lukas, blocker _bugs_ still need to be filed, but are mentioned in the firefox-dev threads: https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000749.html https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000892.html At the moment I'm discussing the action plan with UX. Expect an update soon.

This has been backed out in bug 914180 to 27 (central) so reopening and un-release-noting for Aurora.

Mark for relnote-firefox? when this is actually landed.

"This'll be planned, discussed and developed in the open, but please allow for some internal feedback rounds" How can it be planned/discussed/developed in the open by closed internal feedback? The ideas from the community should come first, then internal discussion. I would be strongly opposed to the move to top idea and the Shorlander concept. Move to the top I oppose because it adds more clutter to the top instead of spreading it around the interface. We should learn from Microsoft's ribbon mistakes not repeat them. Shorlander I oppose because, while pretty, it does not take most of the user interface issues into account (hidden text behind the interface, sites duplicating the interface, etc). I would put forward the following concept 1) Change the findbar to a sidebar 2) Add "find in text" as a search provider 3) Use the sidebar to display options/buttons 4) Use the sidebar to display a list of results within the text 5) Re-engineer ctrl+f to manage search provider selection with the following logic: When focus is off the search area: - ctrl+f = go to search area and select "Find in text" search provider When focus is on the search area: - if search area is empty, ctrl+f = toggle to next search provider (repeatable) - if search area is not empty, ctrl+f = select all, ctrl+f again = toggle to next search provider (repeatable) // this specific option is not ideal, ideally it would be ctrl+a to select all and ctrl+f would only toggle - I only included this because of current behaviour of ctrl+f. 6) Find sidebar does not appear until text is typed and enter or search icon pressed. This is simply to account for the use case of someone hitting ctrl+f, typing then using ctrl+f to toggle to the desired search provider. Structuring it in this manner would place searching all in one UI location allowing for more users to discover it (currently if you don't know ctrl+f you're unlikely to know you can find in text). By using the sidebar structure you add a location for results to be displayed and eliminate any possibility of the find in text UI hiding the text that is found. Implementation of the results list would bring the feature up to date with more current UI standards. Addon developers could potentially take advantage of the new structure to provide other forms of searching within text such as regex or related searches/alternate spellings/etc. Making ctrl+f the controlling shortcut can eventually free up ctrl+k (all), ctrl+e (windows), and ctrl+j (linux) for other uses if desired.

Witness "Tastes differ": just as much as you're against the concept, I'm in love with it. Australis was and is the way to go since Mozilla has to catch up with today's competition regarding the UI. Since _all_ browsers moved and centralized commands and menus at the top, it's just natural to do the say with the find bar. Leaving it at the bottom, forces users to look down into the bar and then up at the page again. This neither follows the natural workflow (e.g. like reading a book or website) nor does it help improve it. In fact, it's quite the contrary. Since it's the last bar remaining at the bottom, IMHO it's about time Mozilla fixes that remnant of ancient times cluttering the UI. Regarding your suggestions: using a sidebar consumes too much screen space and having several (and sometimes quite conflicting) actions upon pressing CTRL+F isn't good either.

Leaving out personal preference and looking at facts your statement is both conflicting and erroneous. If you look at eye movement/reading theory in UI you'll note that any text outside of 4-6 characters from the focal point will not be processed fully by the brain. The further out from the focal point the more substitution the brain does. As a result, whether at the top or the bottom, the eye movement required will cause the same re-focusing/disruption to workflow. The arguments against increased clutter are very well understood. If you care to read up on it, here's a great paper on the subject: http://web.mit.edu/rruth/www/Papers/RosenholtzEtAlCHI2005Clutter.pdf Either way, there are several assumptions being made: - the focal point at which the user is reading is closer to the top than the bottom - that the user changes focal points to do a ctrl+f search - the document is in TTB format - moving to the top will "catch up" to the competition Addressing those assumptions Catching up to the competition First we'd need to look at what the competition is doing. -Internet Explorer uses a slide down model, this was already mentioned as being a bad thing in this bug (see links to mailing list). -Chrome uses a movable pop over model with limited options. This type of pop over model has been fraught with problems in the past due to the ease at which a site can mimic the UI and provide non-standard behaviour. It also presents the problem of possibly being over top of the text being sought. -Safari does something similar to what I suggested, except they send the info to the default search provider, no matter what, and only after you type can you select "find in page". Once selected they use a bottom bar for the next/previous/highlight interface. There is no clear trend looking at browsers, especially if you look at mobile as well. The trend overall has been to reduce the number of UI elements at any given time, especially by combining them. Mozilla did this in the past with the "awesome bar". My suggestion would combine two very similar features and only take up additional screen space upon searching the document. This style of sidebar with results is also consistent with other UIs like Office, various PDF readers, etc. The sidebar does take up a lot of space, however, provides a system which is far more familiar with users: search + results. Clicking next/previous dozens of times is far more annoying than having a list of results to skim through and click. This is especially true when re-finding in a large document. The document is in TTB format This is often forgotten in browser UI design, not all documents are top to bottom. Either way, this goes to the issue of whether clustering elements all at the top is beneficial or whether an "exterior" interface has benefit. I'm not sure if Mozilla has looked at this, especially on a BTT/LTR culture, or just follows trends. Focal point issues These really come down to personal preference. Where on the screen someone reads depends on so many factors, many external to the browser (distance to the screen, size of the screen, orientation, etc), that it's really impossible to have a one size fits all solution. What we do know is that the person will have to re-focus/interrupt workflow if they look at it. Regarding ctrl+f You state having "several actions isn't good", this is confusing as that is the current behaviour (ctrl+f once brings up the findbar and places the carat in the search box. After you type something and hit ctrl+f again it acts in the same manner as ctrl+a). Could you clarify what you mean and also expand on what conflicts you referred to? Cheers

Once the UX is sorted this could be an interesting QX bug. Maybe it could be marked as such.

Since APZ is shipping now, together with E10S, there is a chance that a reboot of the original patch could work without hitting the performance issues of before APZ. Markus, sorry for needing to ask, but would do you think?

s/would/what/

(In reply to Mike de Boer [:mikedeboer] from comment #40) > Since APZ is shipping now, together with E10S, there is a chance that a > reboot of the original patch could work without hitting the performance > issues of before APZ. It's possible, but there's a lot of detail that we should hammer out first. I'm not sure how the original patch worked, but I'm interested in things like: - when the find bar appears, does the scroll position visible to web content change? - what happens to fixed position items at the top of the screen? Do they get pushed down, or overlapped? - should we fire a resize event to content? Superficially the problem seems similar to the dynamic toolbar in Fennec, and will probably run into many of the same problems that we did when implementing that. The experience there is not great even now.

moving the Find bar to the top would fix this bug (relevant to Windows tablets) https://bugzilla.mozilla.org/show_bug.cgi?id=1263062

Since my bug was marked as duplicate to this one, I want to mention a few things: 1) All other user interface elements (tabs, address bar etc.) are at the top of the window. This leads to unnecessary mouse paths, especially if you have the taskbar at the top of the screen, too, like in many Linux distributions. Then you should actually never have a reason to move your mouse cursor to the bottom of the screen. But also on Windows it feels quite misplaced to have the find bar at the bottom of the page. 2) As others said, the find bar should ideally not occupy a full line, just as much space as it actually needs. Widescreen monitors are the new standard. There you should avoid as many horizontal bars as possible. A design proposal can be found here: https://bug1364532.bmoattachments.org/attachment.cgi?id=8867304 3) All this and many more useful things are implemented by the addon "FindBar Tweak". This is a featured addon, used by more than 30,000 users. However, your management has decided to set everything on fire and exterminate all user interface related addons soon. The author of "FindBar Tweak" already said that such an addon will not be possible with WebExtentions APIs. So, please, Mozilla, please do us a favor and integrate parts of this wonderful addon in Firefox out-of-the-box. Sometimes I have the feeling Mozilla employs more pyromaniacs than actual developers. Please proof me wrong...

A much better way to show the find bar, at the top of the page and less cluttered. Designed by AMO user Quicksaver.

I was hoping you would clarify what several/conflicting actions you were referring to in comment #36 as it isn't clear at all what you're talking about. If the only reason to do it is "to be like other browsers" then this should be closed. There should be a good reason for changing UI elements, not just personal preference/keeping up with with Jones' (the latter strategy has completely failed to keep Firefox's userbase).

No, it's me who was hoping for some kind of clarification. A clarification after about 3 years in your end. Unfortunately, it seems, you're unable to clarify it yourself. Of course, it's not the only reason. In fact, I really don't care what other browsers are doing - if I would, I might be already gone in face of several wrong decisions done in the recent past of Firefox. But enough with the chit chat. The main reason I and, as this bug showed already, many other people insist on a findbar at the top is simply consistency. Every other user control is located at the top, hence going down all the way (talking about a 2,560 x 1,440 display here - upright, BTW) for just one control left out at the bottom of the window, is just ridiculous. And if it'd be 1,920 x 1,080 in landscape, you ask? Well, it's the same: one has to go down about 1,000 pixels just because of this underestimated feature whose developers are not losing users because of a lack of speed. They're losing market share because they're not listening what their users want - and discuss with little things for more than 3 years without any progress, without any option and, most importantly, without any action taken or survey initiated. That's why. So, finally start accepting that it's so such better to have "controls at the top, page/content below" than to wait another 3 years or trying to force users to use Firefox your way. As Mozilla (kind of) put it lately: "our browser, made for the people" - now deliver what people want and not what's your preference.

I agree with Martin. I would very much like the find bar moved to the top. My cursor is usually in the top right of the screen, so having to move to the bottom left is a lot more jarring and inconvenient than the alternative, which would be having the page jump down a couple lines (although, I don't see why this needs to be the case either, why not just have it cover up whatever elements it appears in front of?) Anyway, the conversation has been ongoing for 5 years. There are many hits if you search online for this topic. There was even a popular (now abandoned) extension that sought to solve this problem. If Mozilla is set on having their find bar be on the bottom, I'll understand, they've made their decision. But PLEASE at the very least I'd like the ability to set the Find Bar's position myself, having it up top will be a huge improvement to my workflow.

It should be moved to the top because Windows tablets are only going to get more common with ARM-powered devices coming out recently (and more coming out later this year). I think it would be unnecessarily complex to have the find bar 'slide' up and be on top of the on-screen keyboard, it would be much easier to just have it up top like Edge and Chrome do. Again, here is the report https://bugzilla.mozilla.org/show_bug.cgi?id=1263062