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:
*** Bug 249491 has been marked as a duplicate of this bug. ***
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'.
(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.
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?
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?
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.
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. :)
*** Bug 250486 has been marked as a duplicate of this bug. ***
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).
They have moved the Find toolbar to the bottom, so this assures me that when this bug is fixed, it will be done right.
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.
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
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.
> 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.
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.
Is this not a bug for Toolkit instead of Firefox?