Last Comment Bug 869543 - Move findbar to the top
: Move findbar to the top
Status: NEW
p=0
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
: -- normal with 10 votes (vote)
: Firefox 26
Assigned To: Mike de Boer [:mikedeboer]
: Manuela Muntean [Away]
Mentors:
: 254687 1018924 1233139 (view as bug list)
Depends on: 248715 776708 893011 893013 893016 893167 893446 893672 903564 903599
Blocks: 565552 896405 891786 892946 914180
  Show dependency treegraph
 
Reported: 2013-05-07 10:28 PDT by Mike de Boer [:mikedeboer]
Modified: 2016-04-29 10:18 PDT (History)
39 users (show)
majuki: needinfo? (eagle3386)
mmucci: firefox‑backlog+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
affected
affected
affected


Attachments
Move findbar to the top (8.75 KB, patch)
2013-05-07 10:29 PDT, Mike de Boer [:mikedeboer]
no flags Details | Diff | Splinter Review
Move findbar to the top (6.01 KB, patch)
2013-07-10 12:18 PDT, Mike de Boer [:mikedeboer]
dao+bmo: review+
Details | Diff | Splinter Review
Move findbar to the top (5.98 KB, patch)
2013-07-11 03:34 PDT, Mike de Boer [:mikedeboer]
mdeboer: review+
Details | Diff | Splinter Review
Move findbar to the top (5.93 KB, patch)
2013-07-11 03:48 PDT, Mike de Boer [:mikedeboer]
mdeboer: review+
Details | Diff | Splinter Review

Description Mike de Boer [:mikedeboer] 2013-05-07 10:28:29 PDT
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 1 Mike de Boer [:mikedeboer] 2013-05-07 10:29:50 PDT
Created attachment 746502 [details] [diff] [review]
Move findbar to the top
Comment 2 Frank Yan (:fryn) 2013-05-07 10:50:10 PDT
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.
Comment 3 Frank Yan (:fryn) 2013-05-07 14:33:50 PDT
And, as always, thank you for working on this! :)
Comment 4 Dão Gottwald [:dao] 2013-07-06 04:44:13 PDT
*** Bug 254687 has been marked as a duplicate of this bug. ***
Comment 5 Dão Gottwald [:dao] 2013-07-09 00:32:11 PDT
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?
Comment 6 Mike de Boer [:mikedeboer] 2013-07-10 12:18:53 PDT
Created attachment 773477 [details] [diff] [review]
Move findbar to the top

Excellent suggestion, Dão, to introduce the attribute. Makes for a lot cleaner implementation!
Comment 7 Dão Gottwald [:dao] 2013-07-11 01:28:31 PDT
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
Comment 8 Dão Gottwald [:dao] 2013-07-11 01:38:17 PDT
(In reply to Dão Gottwald [:dao] from comment #7)
> nite: border-top-style: none;

nit :)
Comment 9 Mike de Boer [:mikedeboer] 2013-07-11 03:34:31 PDT
Created attachment 773879 [details] [diff] [review]
Move findbar to the top

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.
Comment 10 Mike de Boer [:mikedeboer] 2013-07-11 03:48:31 PDT
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.
Comment 11 Mike de Boer [:mikedeboer] 2013-07-11 03:58:42 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/60865db5f5dc
Comment 12 Ryan VanderMeulen [:RyanVM] 2013-07-11 19:09:35 PDT
https://hg.mozilla.org/mozilla-central/rev/60865db5f5dc
Comment 13 Alice0775 White 2013-07-12 06:11:43 PDT
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.
Comment 14 Luís Miguel [:quicksaver] 2013-07-12 08:09:05 PDT
(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?
Comment 15 Mike de Boer [:mikedeboer] 2013-07-12 08:10:36 PDT
(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?
Comment 16 Jim Jeffery not reading bug-mail 1/2/11 2013-07-12 08:12:32 PDT
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'
Comment 17 Mike de Boer [:mikedeboer] 2013-07-12 08:14:16 PDT
(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?
Comment 18 Jim Jeffery not reading bug-mail 1/2/11 2013-07-12 08:30:45 PDT
(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
Comment 19 Olli Pettay [:smaug] (vacation Aug 25-28) 2013-07-12 12:44:45 PDT
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.
Comment 20 soufian.j 2013-07-12 13:13:25 PDT
Why can't you place the findbar at the top, without moving the content? I just noticed toggling toolbars also moves content.
Comment 21 Pache 2013-07-18 04:53:23 PDT
(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'

Please do this. Add a option to allow the users to put it where they want, top or bottom.
Comment 22 Manuela Muntean [Away] 2013-09-03 05:03:12 PDT
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.
Comment 23 Alex Keybl [:akeybl] 2013-09-13 08:42:45 PDT
Setting relnote flag for whenever this sticks (26 or later due to bug 914180).
Comment 24 Lukas Blakk [:lsblakk] use ?needinfo 2013-09-13 13:14:10 PDT
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?
Comment 25 Justin Dolske [:Dolske] 2013-09-17 16:12:14 PDT
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.
Comment 26 Lukas Blakk [:lsblakk] use ?needinfo 2013-09-17 16:13:34 PDT
Mike - are there any remaining blockers or a chance this will not ship that you are aware of?
Comment 27 Mike de Boer [:mikedeboer] 2013-09-19 08:00:41 PDT
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.
Comment 28 Lukas Blakk [:lsblakk] use ?needinfo 2013-09-20 11:30:20 PDT
This has been backed out in bug 914180 to 27 (central) so reopening and un-release-noting for Aurora.
Comment 29 Guillaume C. [:ge3k0s] 2013-10-13 05:43:29 PDT
Is there any news about this ? It's really frustrating to have it back at the bottom. It was much logical to have it on top. Any replacement plans ? (partial find bar ?)
Comment 30 Lukas Blakk [:lsblakk] use ?needinfo 2013-12-05 15:00:34 PST
Mark for relnote-firefox? when this is actually landed.
Comment 31 Mike de Boer [:mikedeboer] 2014-06-03 01:57:58 PDT
*** Bug 1018924 has been marked as a duplicate of this bug. ***
Comment 32 Guillaume C. [:ge3k0s] 2014-06-10 01:14:34 PDT
Some new concept by Shorlander : http://people.mozilla.org/~shorlander/mockups/FindBar/Findbar.png
Comment 33 Alice0775 White 2014-06-10 01:38:13 PDT
(In reply to Guillaume C. [:ge3k0s] from comment #32)
> Some new concept by Shorlander :
> http://people.mozilla.org/~shorlander/mockups/FindBar/Findbar.png

It is terrible UI.
No UI must disturb the contents of web page!
Comment 34 Mike de Boer [:mikedeboer] 2014-06-10 03:24:57 PDT
(In reply to Guillaume C. [:ge3k0s] from comment #32)
> Some new concept by Shorlander :
> http://people.mozilla.org/~shorlander/mockups/FindBar/Findbar.png

It's too premature too post this as they're concepts. This'll be planned, discussed and developed in the open, but please allow for some internal feedback rounds...
Comment 35 JDev 2014-09-29 11:50:09 PDT
"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.
Comment 36 Martin Baranski 2014-09-29 12:43:12 PDT
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.
Comment 37 JDev 2014-09-29 14:19:42 PDT
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
Comment 38 Gingerbread Man 2015-12-16 18:42:17 PST
*** Bug 1233139 has been marked as a duplicate of this bug. ***
Comment 39 Guillaume C. [:ge3k0s] 2016-02-29 08:03:11 PST
Once the UX is sorted this could be an interesting QX bug. Maybe it could be marked as such.
Comment 40 Mike de Boer [:mikedeboer] 2016-04-29 02:44:42 PDT
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?
Comment 41 Mike de Boer [:mikedeboer] 2016-04-29 02:45:14 PDT
s/would/what/
Comment 42 Kartikaya Gupta (email:kats@mozilla.com) 2016-04-29 10:18:12 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.