User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 SeaMonkey/2.1 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 SeaMonkey/2.1 (RC1) My preferences are set in [Edit > Preferences > Browser > Tabbed Browsing] to "Hide the tab bar when only one tab is open". When I open a tab from a link in the page I am currently viewing, the tab bar launches and causes that current page to drop down a vertical space equal to the height of the tab bar. If I had my cursor positioned on the current page at a particular line, the result is that my cursor is now positioned about 1-1/2 lines higher. That is, the page moves down 1-1/2 lines relative to where the cursor was positioned. Reproducible: Always Steps to Reproduce: 1. Set the preference for "Hide the tab bar when only one tab is open". 2. With only one tab (no tab bar), do a bugzilla.mozilla.org search that results in a list of several bugs. 3. Place the cursor over one of the bug reports, but not the first one. 4. Click the mouse without moving the cursor. Actual Results: At step #4, the cursor becomes positioned over the bug just above the one selected. Expected Results: At step #4, the cursor should remain on the link selected.

I think that's expected (WONTFIX). Suddenly moving the mouse cursor without user interaction would make even more people file bug reports thinking that there was something wrong with SeaMonkey.

This was NOT the behavior in SeaMonkey 2.0.x. I submitted this bug report when I found myself actually doing the "Steps to Reproduce". I was working my way down a list of bug reports from running a search query. After selecting the first report that I wanted to view -- in a new tab -- I selected it again because it was down from my cursor's position.

I'm not able to duplicate your steps in 2.0.15? (Or I am not understanding them correctly?) 0. set the following preferences > Hide the tab bar when only one tab is open > unset, Switch to new tabs opened from links > Middle-click, ... on links in a Web page (Opens tabs instead of windows) 1. load http://www.seamonkey-project.org/start/ (one window with that single page open at this point) 2. center-click 'Documentation' > Tab bar appears > Documentation & Help opens in a background tab > page focus remains at http://www.seamonkey-project.org/start/ > cursor position is focused (somewhere around) SeaMonkey Community (possibly depending on browser screen size, theme ...) Or use this for step 1. 1. load https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=32000 And I see no change in what I've described in SeaMonkey 2.2.

The problem did not exist in SeaMonkey 2.0.14 (the last 2.0.x version I used before updating to 2.1). It does exist in 2.1. When I open a second tab, the tab bar is created in space that was previously allocated to the display of a rendered Web page. The display drops down so that the top line of the display prior to the creation of the tab bar remains the top line in the display. While viewing a bugzilla.mozilla.org query report (only tab, no tab bar) and selecting a bug report to appear in a new tab (thus creating the tab bar), that is a drop-down of about two lines. However, the cursor does not move with the display and is thus two lines too high. While using my cursor to scan visually down the display, I again scan two entries in the query report that I already scanned. (Hmm. Did I already request a display of that bug report in a new tab?) I did not see this as a problem in 2.0.14 because the new tab displayed. I had to return to the old tab to continue my scan. Now, with 2.1 the old tab remains the current display.

> I did not see this as a problem in 2.0.14 because the new tab displayed. I had to return to the old tab > to continue my scan. Now, with 2.1 the old tab remains the current display. Huh? Then toggle: Edit | Preferences | Browser -> Tabbed Browsing => Switch to new tabs opened from links, & links will then open as they did for you in 2.0. Further, while the /screen/ position may have changed, the cursor focus has not. You can verify that by entering the keyboard combo, Ctrl+Enter, & you will see that the same link is opened once again in another tab.

Re comment #5: Huh? back at you. :) My preferences are set the way I want them, and they work the way I set them. They are set as follows: * Open links meant to open a new window in: A new tab in the current window. * When scripts want to open a new window: Always divert windows into tabs. * Open links passed from other applications in: A new window. As you describe in your last paragraph, the cursor focus does not change. However, the position of the cursor also does not change while the vertical position of the page under the cursor has changed. Either the cursor should follow the page, or else the position of the page should not change (thus causing the created tab bar to cover the top lines that were previously displayed). If the cursor were already at the bottom of the displayed page, the former case might indeed be a problem since the bottom of the page would then move below the viewable browser window. I do not consider the latter case to be a problem and believe it is likely the easier to implement.

While my examples use Bugzilla queries, I see similar problems at other Web sites. I was reading Canadian news at <http://www.cbc.ca/news/> in a one-tab session (no tab bar). In a list of links to individual news articles, I saw a headline that seemed interesting. I middle-clicked on the link to open it in a new tab and thus launched the tab bar. My cursor was then actively hovering over a previous link. Proper operation should result instead in my cursor hovering over the link I just selected.

Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 SeaMonkey/2.8 Today, I selected a link that was at the bottom of the view port, to open in a new tab. At the time, I had only one tab open. Thus, the tab bar was not present. When the link opened and the tab bar appeared, the page scrolled and caused the line containing the link to drop below the view port (no longer visible). This is quite wrong. The tab bar should instead cover the top line of the view port without causing any page scrolling.

I also see this problem with the bar that is launched when the preference variable accessibility.blockautorefresh is True and a Web page tries to refresh. Furthermore, the problem also occurs when the menu bar, tool bar, or (with the PrefBar extension installed) Preference tool bar are either hidden or else reduced.

(In reply to David E. Ross from comment #8) > The tab bar should instead cover the top line of the view port > without causing any page scrolling. Actually this is the same ball from another side: if you open a link from the very top of the page, it would be overlapped (with cursor?) by tab bar. Moreover, when the initial page is rather small (e.g. 1/3 of vertical window size), it still should be overlapped at the top some way, witch is quite strange with a lot of unused space at the bottom. Another way (to scroll the page together with cursor) seems to be more formalizable (even with the overlapped cursor issue). But it is much less intuitive for end users with mice and touchpads because of the nature of mouse positioning: it's absolute for the whole screen(s) not depending of window positions and scroll events. When using another pointing logic (caret browsing via F7), the cursor scrolls with the content natively. Thus there seems to be no way to resolve the problem right, though sometimes it could be really annoying. Maybe some day we'll see something like flowing panels in gui and the tab bar could be moved to the window bottom...

See bug #248715 and bug #893446 for similar problems in Firefox. The impact described there is that the user's eyes are focused on a particular line of a Web page, but the Web page jumps whenever a new toolbar or other artifact appears at the top of the view port. It is partially because of the problem described in bug #893446 that I have set browser.findbar.enabled to "false" and continue to use a dialogue popup for Find. Bug #248715 is a more generalized statement of the problem, but it is specific to Firefox and thus does not include SeaMonkey in its scope. To me, a solution would be to provide a user option whether or not to shift the page in the view port when inserting a bar at the top of it.