Status

()

Firefox
General
4 years ago
a month ago

People

(Reporter: mikedeboer, Assigned: mikedeboer, NeedInfo)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

Trunk
Firefox 26
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox25 affected, firefox26 affected, firefox27 affected, firefox28 affected, firefox29 affected)

Details

(Whiteboard: p=0)

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

4 years ago
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.
(Assignee)

Updated

4 years ago
Assignee: nobody → mdeboer
(Assignee)

Comment 1

4 years ago
Created attachment 746502 [details] [diff] [review]
Move findbar to the top
Attachment #746502 - Flags: review?(fyan)
(Assignee)

Updated

4 years ago
Depends on: 776708
(Assignee)

Updated

4 years ago
Status: NEW → ASSIGNED

Comment 2

4 years ago
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

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

Updated

4 years ago
Attachment #746502 - Flags: review?(fyan)

Updated

4 years ago
Blocks: 565552
Component: Toolbars and Customization → General

Updated

4 years ago
Duplicate of this bug: 254687

Updated

4 years ago
Blocks: 890613
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?
(Assignee)

Comment 6

4 years ago
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!
Attachment #746502 - Attachment is obsolete: true
Attachment #773477 - Flags: review?(dao)
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
Attachment #773477 - Flags: review?(dao) → review+
(In reply to Dão Gottwald [:dao] from comment #7)
> nite: border-top-style: none;

nit :)
(Assignee)

Comment 9

4 years ago
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.
Attachment #773879 - Flags: review+
(Assignee)

Updated

4 years ago
Attachment #773477 - Attachment is obsolete: true
(Assignee)

Comment 10

4 years ago
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.
Attachment #773879 - Attachment is obsolete: true
Attachment #773881 - Flags: review+
(Assignee)

Comment 11

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/60865db5f5dc
Blocks: 891786
https://hg.mozilla.org/mozilla-central/rev/60865db5f5dc
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25

Updated

4 years ago
Depends on: 892946
Blocks: 892946
No longer depends on: 892946

Comment 13

4 years ago
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.

Updated

4 years ago
relnote-firefox: --- → ?
relnote-firefox: ? → ---
(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?
(Assignee)

Comment 15

4 years ago
(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'
(Assignee)

Comment 17

4 years ago
(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?
Depends on: 893011
Depends on: 893013
(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

Updated

4 years ago
Depends on: 893016
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

4 years ago
Why can't you place the findbar at the top, without moving the content? I just noticed toggling toolbars also moves content.

Updated

4 years ago
Depends on: 893167
Depends on: 893446
Depends on: 893672

Comment 21

4 years ago
(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.
Blocks: 896405
Depends on: 897751
No longer depends on: 897751

Updated

4 years ago
Depends on: 903564

Updated

4 years ago
Depends on: 903599

Updated

4 years ago
QA Contact: manuela.muntean
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.

Updated

4 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

4 years ago
Blocks: 914180
Setting relnote flag for whenever this sticks (26 or later due to bug 914180).
relnote-firefox: --- → ?
Target Milestone: Firefox 25 → Firefox 26
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?
Flags: needinfo?(dolske)
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.
Flags: needinfo?(dolske)
Mike - are there any remaining blockers or a chance this will not ship that you are aware of?
Flags: needinfo?(mdeboer)
relnote-firefox: ? → 26+
(Assignee)

Comment 27

4 years ago
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.
Flags: needinfo?(mdeboer)
This has been backed out in bug 914180 to 27 (central) so reopening and un-release-noting for Aurora.
Status: VERIFIED → REOPENED
relnote-firefox: 26+ → ?
Resolution: FIXED → ---

Updated

4 years ago
No longer blocks: 890613
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 ?)
Mark for relnote-firefox? when this is actually landed.
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected
status-firefox29: --- → affected
relnote-firefox: ? → ---

Updated

4 years ago
Blocks: 950073
Whiteboard: [triage]

Updated

4 years ago
Whiteboard: [triage]

Updated

4 years ago
No longer blocks: 950073

Updated

4 years ago
Blocks: 950073
Whiteboard: [feature] p=0
Depends on: 248715

Updated

3 years ago
No longer blocks: 950073
Flags: firefox-backlog+
Whiteboard: [feature] p=0 → p=0
(Assignee)

Updated

3 years ago
Status: REOPENED → NEW
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1018924
Some new concept by Shorlander : http://people.mozilla.org/~shorlander/mockups/FindBar/Findbar.png

Comment 33

3 years ago
(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!
(Assignee)

Comment 34

3 years ago
(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

3 years ago
"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

3 years ago
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

3 years ago
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
Flags: needinfo?(eagle3386)

Updated

2 years ago
Duplicate of this bug: 1233139
Once the UX is sorted this could be an interesting QX bug. Maybe it could be marked as such.
Flags: needinfo?(philipp)
(Assignee)

Comment 40

a year ago
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?
Flags: needinfo?(mstange)
(Assignee)

Comment 41

a year ago
s/would/what/
Flags: needinfo?(philipp)
(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.
Flags: needinfo?(mstange)

Comment 43

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

Updated

2 months ago
Duplicate of this bug: 1364532

Comment 45

2 months ago
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...

Comment 46

2 months ago
Created attachment 8867460 [details]
Design proposal

A much better way to show the find bar, at the top of the page and less cluttered. Designed by AMO user Quicksaver.
You need to log in before you can comment on or make changes to this bug.