982323 - Breakdown: Avoid shifting the page when toolbars appear or disappear

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, enhancement)

Description

[Marco Mucci [:MarcoM]]

+++ This bug was initially created as a clone of Bug #248715 +++

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040624 Firefox/0.9.0+
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040624 Firefox/0.9.0+

Option set required to experience behavior described:
"hide the tab bar when only one website is open" is selected
"Select new tabs opened from links" option is deselected

Actual Results:
When one has only one webpage open, and a link is opened in a new tab, the
entire webpage is shifted down slightly to accomidate for the tab bar appearance.

I don't think this is the most optimal behavior, because the user loses the
place on which his cursor was hovering, which is very distracting, especially
while reading forums.  (places where you open a lot of pages into background
tabs, and then later read them one by one)

I can partially understand the reasoning behind the current behavior, and maybe
there is still a place for it, for instance, in the special case where the page
is scrolled all the way to top.  This way, top menus on pages won't be covered
up by the tab bar.  But for the sake of being simple and unconfusing, I propose
providing an about:config option of doing away with this page shifting altogether.

browser.tabs.barappears.shiftpagedown [b]true[/b] (default)

Expected Behavior of this Enhancement:
If this option is set to false, whenever the tab bar appears, it won't shift the
page down.

Thinking ahead:
If this enhancement is implemented, I figured it would be best to make sure that
people who use Tabbrowser Extensions and place the tabs at the bottom could
still retain their expected behavior.  The solution is to just have those people
leave the option set at its default value. As is always best, those who know
what the option does can change it, but those who don't won't be affected.

Reasoning for the option's nomenclature:
Note that I called the option "shiftpagedown" and not "pageshift" to specify the
important point that it isn't an all inclusive disabling of the page shift, it
only applies to the behavior of the page being shifted *down*. 

I suppose to make the option set symmetrical, in the situation where the user
places the tabs at the bottom and happens to *want* the page to shift up when
the tab bar appears, another default option called
"browser.tabs.barappears.shiftpageup false" *could* be implemented as well.  I
personally see no reason for this though, and frankly feel it is pointless.

Enhancement Test Case:
Here is a test case that you can try with Tabbrowser Extensions if you would
like.  This current shifting behavior is not present in Firefox when the tab bar
is at the *bottom* the browser; so you can use TBE to get an idea of what this
option would be like.  

1.  Use TBE to place the tab bar at the *bottom* of the browser 
2. Require that links that are opened in tabs open in the background
3.  Make the tab bar hide when only one tab is open.

As you will see, no page shifting occurs with this set of options and the effect
is perfect;  you just lose the slight amount of viewing area at the bottom that
is covered up by the tab bar opening.

Reproducible: Always
Steps to Reproduce:

Comment 1

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

This also makes sense for our various notification bars.

Comment 2

[Neil Deakin]

Which toolbars are being referred to and when would this apply? The description is referring to the tabbar but that can no longer be hidden (bug 855370).

Comment 3

[:Gavin Sharp [email: [e-mail]]]

The primary goal is to make it possible to move the findbar on top without the various "jank" issues that resulted when we tried that last time (see dependency list of bug 869543).

Seconday goal is to make notification bars and other toolbars that appear/disappear not cause that same jank.

Comment 4

[u279076]

Pre-emptively flagging for in-testsuite since I think this might be able to be covered by automation.

Ioana, please ensure this gets assigned for sign-off in this iteration.

Comment 5

[Neil Deakin]

Anthony, Ioana, the 'Breakdown' bugs are being used as tracking bugs. The patches would go in other bugs once this feature has been broken into subtasks each with their own bugs, or in the original bug 248715. You likely wish to flag that bug instead.

Comment 6

[u279076]

Marco reached out to me and informed me that this bug just tracks the work breakdown so I'm marking this as [qa-].

Comment 7

[Neil Deakin]

So I think there are three cases here:

- When the findbar is on the top of the window, adjust the scroll position.
- When a notification bar opens
- When the user shows and hides a toolbar. In this case, I don't think we want to make such a change.

For the first two, which would both be implemented the same way:

Because the two cases don't overlap the content area, the issue seems to be to adjust the scroll position of the page to match the height of the newly revealed or removed toolbar.

There are some complexities:

- they slide open using a transition, yet the scroll position isn't something you can transition.
- if the page isn't large enough, you can't scroll it at all. It's also possible that the scrollbar could appear/disappear part way through the sliding of the toolbar.

Comment 8

[Neil Deakin]

Bug 780512 is about implementing a transition for the scroll position.

Comment 9

[Neil Deakin]

The find bar on top bug is 869543. I don't think any additional bugs are needed except for some work to do this the original bug 248715, which should be a general function to handle this for any toolbar that might need it.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Neil Deakin from comment #7)
> So I think there are three cases here:
> 
> - When the findbar is on the top of the window, adjust the scroll position.
> - When a notification bar opens
> - When the user shows and hides a toolbar. In this case, I don't think we
> want to make such a change.
> 
> For the first two, which would both be implemented the same way:
> 
> Because the two cases don't overlap the content area, the issue seems to be
> to adjust the scroll position of the page to match the height of the newly
> revealed or removed toolbar.
> 
> There are some complexities:
> 
> - they slide open using a transition, yet the scroll position isn't
> something you can transition.
> - if the page isn't large enough, you can't scroll it at all. It's also
> possible that the scrollbar could appear/disappear part way through the
> sliding of the toolbar.

How would we handle web pages like Zimbra that are set to take 100% of the viewport and so scrolling the page isn't an option?

Comment 11

[Neil Deakin]

Since it appears some work on this was already done by other people, I'm not sure why I should be assigned to this.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

This is a breakdown bug - you completed the breakdown.