The new find bar shifting down content

The Wanderer wanderer at
Tue Aug 13 12:54:11 UTC 2013

On 08/13/2013 05:53 AM, Gervase Markham wrote:

> On 13/08/13 00:15, Ehsan Akhgari wrote:
>> I find the new behavior of the find bar to shift down the whole
>> content when it opens up extremely jarring.
> This doesn't happen for me in yesterday's nightly; has the behaviour
> changed recently?
> I agree that shifting content is irritating. However, a full-width
> overlay is also irritating - even if there is nothing important
> behind the bar, it affects my equanimity that I suddenly can't see
> part of the top of the page. There is also, on my 1920px wide
> monitor, an enormous useless expanse of greyness right across the
> middle of the bar, which seems wasteful.

When opening a new full-width bar, there are a few basic options. The
ones I see offhand are:

A. Overlay it over the existing content, and don't scroll to match.
Disadvantage: Hides previously visible content.

B. Overlay it over the existing content, and scroll to match.
Disadvantage: Changes the current position relative to the beginning/end
of the page.

C. Push the subwindow ("pane"?) where the existing content is displayed
out of the way. Disadvantages: Produces a visible shift in the
already-displayed content.

With bars at the top of the window, I find all three of these to be
highly irritating in different ways. However, for some reason, the same
effect does not apply to bars on the bottom of the window.

For example, the existing at-the-bottom find bar uses what I think is
approach B; pressing Ctrl-F while at the bottom of a page long enough to
need scrolling results in no longer being at the bottom of the page,
although the content of the displayed area does not change. I'm not sure
why, but this does not bother me, although experience has shown that
suddenly finding myself no longer at the top of a page for similar
reasons does bother me. (It might have something to do with how
relatively infrequently I actually am at the bottom of the page.)

A non-full-width bar might help avoid that, but it has its own

As far as I can tell, the root of why the "shifting content" / "change
in current relative page position" factor bothers me is something which
I think of as a fundamental UI principle, which I have expressed as: "No
UI element should ever change location, unless I as the user explicitly
tell it to.".

A non-full-width bar is essentially an overlay, and as such, will cover
up part of the page content. For transient overlays which are intended
to exist only long enough for the user to interact with them once (e.g.
the "do you want to remember this password?" dialog), this is
acceptable, but for something intended to be more persistent it is not.

The obvious way to avoid that problem would be, as suggested, to have
the bar move when needed - much as the popup for "page load status"
notifications does, except based on overlapping with found text rather
than on mouseover.

However, moving in that way violates this basic principle. A user who
pressed the "next result" button was not intending to say "move the find
bar"; I, at least, would find it quite jarring to see the UI element I'm
interacting with jump from one place to another because I e.g. hit "find
next result".

So using a non-full-width bar in an attempt to avoid violating the "UI
elements should not move" principle actually just introduces another

The trick is to find the solution which has the fewest and/or least
significant such problems, relative to the benefits it can provide - and
I strongly suspect that the best compromise is in fact a full-width bar
on the bottom, with option B, much as we currently have. (There's
nothing to say we can't or shouldn't have additional functionality
within that bar, of course.)

    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger

More information about the firefox-dev mailing list