248715 - Avoid shifting the page when toolbars appear or disappear

Status: REOPENED

(Firefox :: Toolbars and Customization, enhancement)

Description

[mmortal03]

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

[Jesse Ruderman]

*** Bug 249491 has been marked as a duplicate of this bug. ***

Comment 2

[Max Waterman]

must be all hardware, surely (I'm on Apple).

I've read the Description here too, but I still think this is a bug, and should
not be categorised as an enhancement.

When opening pages in tabs in the background, it needs to not shift the page.
When opening pages in the foreground, then it is fine for it to shift the page down.

Of course, I can't change the severity. Please consider changing it to 'bug'.

Comment 3

[mmortal03]

(In reply to comment #2)
> must be all hardware, surely (I'm on Apple).
> 
> I've read the Description here too, but I still think this is a bug, and should
> not be categorised as an enhancement.
> 
> When opening pages in tabs in the background, it needs to not shift the page.
> When opening pages in the foreground, then it is fine for it to shift the page
down.
> 
> Of course, I can't change the severity. Please consider changing it to 'bug'.

Yeah, I thought about and then forgot about that, we need to apply different
behavior if opening pages in a new foreground tab.  My solution to that problem
is already built in to my request, though :).  The default behavior is to
"Select new tabs opened from links".  So, you don't fool with the proposed
option either, you leave browser.tabs.barappears.shiftpagedown set to the
default as well.

When you DO select the option "Select new tabs opened from links", you would
also go and adjust the proposed option to false.  Very easy. :)
We COULD request that when Select new tabs opend from links is true, that 
the shiftpagedown option is automatically set to false, and vice versa, but I
bet that goes against normal option protocol, and would not allow the two
configurations of true, true and false, false (however useless "true, true" is,
false, false IS the current default behavior, and should be left intact and
available.)

As for the bug categorization, I agree, this is a toughie to categorize.  I'd
like to hear what some others have to say about it.  My thoughts here are that I
still think it should still be marked as an enhancement, because I am requesting
that the old behavior still be left in as the default option.  If it were a bug,
we would remove the current behavior.

Comment 4

[Max Waterman]

Hrm, I am thinking we need two 'bugs' open then. I'm confident this is not as
intended, and is almost universally an annoyance. I'm not sure an option is
necessary.

To me, this is certainly a bug. Adding the option would be an enhancement, but
I'm not asking for that.

Should I reopen the bug I filed, that was just marked as a duplicate?

Comment 5

[mmortal03]

Well, as long as the fix wouldn't break the desired, current behavior when the
tab bar is at the bottom (with TBE), and as long as we can convince the
developers that the original behavior has no purpose and that it is unintended,
then I am all for simply fixing the problem (just the bug) and offering no
alternative (no enhancement).

I came up with the about.config option idea from the get-go because I predicted
people would be against removing the shifting option all together.  You see, I
am all for erring on the side of caution, and I like avoiding those quickie
"Will Not Fixes" that are assigned rather frequently to stuff like this.  It is
a compromise that I figured was more acceptable to everybody and that I would
still be completely satisfied with.

MAybe I shouldn't be so quick to make compromises?  What do you think?

Comment 6

[mmortal03]

I noticed that with the addition of the new Find Toolbar, that this bug should
not only specifically relate to the shifting that occurs with the Tab Bar
appearing, but with ANY toolbar being added OR removed.

Here is a revision to the about:config option idea, with an edit of the original
option and an addition of the "removed" case, and now with both being set to
"false" by default (my reasoning below):

browser.toolbars.added.shiftpagedown [b]false[/b] (default)
browser.toolbars.removed.shiftpageup [b]false[/b] (default)

With regards to the previously mentioned case where toolbars are added and
removed at the *bottom* with the use of TBE, this is NOT stadard behavior for
Firefox, so I don't think the option naming should take account of this
possibility (eg, making a set of *four* options, two for toolbars appearing from
the top, and two for toolbars appearing from the bottom.  This is unnecessary.)
 Instead, my recommendation for going about keeping compatibility there,
considering that now that we have at least *two* toolbars that are going to be
often added and removed during the course of browsing, is to make NO browser
function or toolbar shift things up OR down by default.  

It *should* be understood though, that both of the above options only apply to
toolbars being added to the top.  Regardless of how those options are set, if a
user DOES happen to use TBE to place his tab bar at the bottom, and for whatever
reason decides to have browser.toolbars.removed.shiftpageup set to true, when
the tab bar appears at the bottom, NO page shifting should occur.  I want to
make this clear, because I have a hunch that the current shifting behavior
functions IRRESPECTIVELY of where the toolbars are added, and it just so happens
that shifting from the bottom is only called for when toolbars are removed
because there was no reason for the programmer to have it called for in the case
of unsupported behavior (TBE).  Logically, when adding toolbars to the bottom,
no shifting should occur ANYWAY, when adding OR removing toolbars, so it is
irrelevant in this respect to add separate options to control this behavior
anyway, but it *is* relevant that the behavior be separate of toolbars at the
top, and that it function accordingly.

Comment 7

[mmortal03]

Remember that when pages are all the way at the top, and a toolbar is removed,
shifting still needs to occur though.  So, in psuedocode, it should work like
this when shifting is disabled and a toolbar is removed:

if (distance_scrolled_down < height_of_toolbar)
shiftpageup(distance_scrolled_down);

in the special case of the tab bar, where there are two tabs open, when closing
the toolbar you are also removing the tab.  For this case:

if (next_in_focus_page's_distance_scrolled_down < height_of_toolbar)
shiftpageup(next_in_focus_page_distance_scrolled_down);

Hopefully, this clears some things up. :)

Comment 8

[Jesse Ruderman]

*** Bug 250486 has been marked as a duplicate of this bug. ***

Comment 9

[Mailer Key]

re: the new find toolbar

When I have lots of tabs open (usually I do; 20+), the time for the toolbar to
appear is very long.  It takes as long as five seconds to completely appear. 
Maybe this is out of scope (so many tabs).

Comment 10

[mmortal03]

They have moved the Find toolbar to the bottom, so this assures me that when
this bug is fixed, it will be done right.

Comment 11

[mmortal03]

One thing to note, remember, this bug only affects people who use the "Hide the
tab bar when only one web site is open" option.  If you turn that option off, no
shifting occurs.

Note: At the moment, 1 pixel page shifting still occurs (and creates a "flicker"
effect) because of an unrelated bug in the tab bar, where if more than one tab
is opened, the tab bar becomes one pixel higher.

Comment 12

[David Regev]

This is [parity-Safari]. Bring up Find in Safari and watch the scrollbar: although the height of the content area decreases as the Find toolbar appears, the page position remains static, because the scroll position is automatically adjusted. You can see this in the beginning of this video[*].

Fixing this bug would allow a whole range of new possibilities, including moving the Find toolbar to the top without the page-shifting problem mentioned in bug 254687.

[*] http://www.youtube.com/watch?v=RnnDk8yBGT0

Comment 13

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

We shouldn't add an option for this because we should just make the right behavior the default. Changing the scroll position when the toolbar appears has the chance of changing the position where the user needs to look to keep their place while reading, but this should only occur when a user opens a new tab and the tab bar appears. In the case of opening a new tab, their eye position is irrelevant since this is new content being loaded.

Therefore, the benefits of making this change are very low and we would be better off putting our efforts towards higher impact bugs.

Comment 14

[Jesse Ruderman]

> We shouldn't add an option for this because we should just make the right behavior
> the default.

Unless you were planning to reopen one of the dups, I don't see how WONTFIXing this bug brings Firefox closer to having the correct behavior.

> In the case of opening a new tab, their eye position is irrelevant since this is 
> new content being loaded.

You seem to be assuming the new tab is selected.  This bug is about the case where the current tab remains selected.

> we would be better off putting our efforts towards higher impact bugs.

In a project like Firefox that has significant volunteer contribution, this is not a valid reason to WONTFIX a bug.

Furthermore, this bug will become more important if/when we move the Find bar to the top.

Comment 15

[David E. Ross]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 SeaMonkey/2.24

Although bug #893446 is marked as "VERIFIED FIXED" as of mozilla26, I still see the viewport jump down when the Find toolbar appears.  This bug should address that as well as the other instances.

Comment 16

[David E. Ross]

Is this not a bug for Toolkit instead of Firefox?