Would it be possible to put the Links toolbar under the tabs? This way it is clear that it belongs to the document you're browsing. Now I'm thinking of it, it might be even better to put the links bar in the document itself, thereby it can also be used in Sidebars etc. But that's another sidestep, I'll maybe file another bug for that I think. So it would look like: [back][forward][reload]___________________| [bookmarks]_______________________________| [Tab1][tab2][|active tab|]________________| |[links toolbar]__________________________| |active document | | | . . . This would also fix bug 102905

makes sense, confirming rfe

Hey, I really like this idea. It makes a lot of sense.

There was a discussion about this at one point in the course of the Link toolbar development. The question then (since there were no tabs) was to put the toolbar in the document space. (Essentially next to instead of over the sidebar.) This mainly dealt with Framesets where different frames had different links. I don't believe a resolution was ever made, but remember that this would be the first "document specific" toolbar. We shouldn't jump into doing this without being sure about the User Interface guidelines.

Changing summary to accomodate frames issue. Old summary: [RFE] Links toolbar IN tab, instead of in Main toolbar. New summary: [RFE] Links toolbar IN tab/frame, instead of in main toolbar.

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

A few more points from my dupe: Having chatted with hyatt and hewitt, we are going to run into problems with auto-show interacting with tabs. I.e. if you change tabs from a linked page to an unlinked page, your tabs will move. This could be very annoying. The solution to this seems to be to move the links toolbar into the content frame, so that it appears at the top of the page. If we fix bug 103097, it would render before the page does, and therefore appear to be the "top" of the page (although it would persist between two <link>ed pages.) In other words, you wouldn't really get any flicker at all. Then, when you have tabs, they appear _above_ the links toolbar, so it appearing and disappearing does not move the tabs. This has a side advantage that we don't lose one tab's worth of sidebar real estate, as we do now. This is probably a longer-term change, but I wanted to get a bug recorded about the idea. Gerv

Stealing summary from bug 103183 (it's worded better). Old: [RFE] Links toolbar IN tab/frame, instead of in Main toolbar. New: Links toolbar should be inside content frame

When you say "the 'top' of the page" do you mean above the viewport? IMO, the toolbar shouldn't scroll with the page.

sballard said in the dupe: I'm not sure I agree with this patch, but the immediate problem (tabs are below links) could be solved just by changing the order of the toolbars by tweaking some position values in overlays, right? I like having my toolbars together at the top of the screen and I don't use tabs. I'd also prefer if my otherwise consistently-placed "top" and "next" items didn't move across half a mile when I open up the sidebar. But then I don't use tabs, so I have a vested interest in the solution that benefits "my" favorite feature. I always assumed tabs would appear at the bottom of the screen, like excel. I guess having them at the top is better, but it does make life harder wrt this bug ;)

> but the immediate problem (tabs are below links) could be solved just by > changing the order of the toolbars Sadly, no. Tabs are not a toolbar. If you don't use tabs, your toolbars will be all together at the top of the screen. It's just one will be shorter than the others. Apparently this is the way IE for Mac does it for the Auction Assistant. HenriS: yes. It would be the equivalent of being position:fixed at the top of the current content area. Gerv

I disagree with moving the links bar below the tabs. 1) The fewer things that shift position when I open the Sidebar, the better. 2) The links toolbar *is* a toolbar, correct? *Other* toolbars do not appear below the tabs, why should this one be treated any differently? The Links Toolbar shouldn't be moved to make it "clear that it belongs to the document you're browsing." The navigation buttons, urlbar, menu bar items, and personal toolbar all also 'belong' to the tab you're browsing in; I don't see those being moved below the tabs... my $0.02

The <link> toolbar should be part of the chrome, not the page. It should definitely not act like position:fixed. Perhaps position:absolute might be tolerable. I do not want to have to scroll back up to the top of the page in order to use the "consistent navigation" feature. If that's all we do, might as well just let authors continue putting <a> links arbitrarily/conveniently (top, side, bottom). Plenty of discussion back in bug 2800 regarding this (from myself, hixie, mpt, and others). Specs too. If <link>s are available, they should be displayed and accessible - not hidden away in a sidebar panel, not scrolled off the page. Otherwise <link> is virtually useless and nobody will use this feature. <Link> is part of <head>, not <body>, for a reason.

Position fixed does keep it at the top of the visible area. So it doesn't scroll with the page. As a remark to the comments on not wanting it "inside" the document: I'd love to be able to use a link toolbar in a sidebar (maybe it should then remove the text and leave only the icons) because a sidebar is nothing more than a webpage with navigation etc in most cases, having such a way to navigate through it makes it ideal to put your sitemap or a dmoz like structure in a sidebar, and keep it browsable. And having it as a "in document feature" enables you to use it anywhere you want, also in frames, sidebars, pop-up windows....

My main point is that *if* the "links" UI is going to be a toolbar (and it looks like that will be the case), it should not be treated differently than the other toolbars in the product. I agree with what Mike Young said in the comment 2001-10-03 18:16: "...but remember that this would be the first "document specific" toolbar. We shouldn't jump into doing this without being sure about the User Interface guidelines."

Then those guidelines should be worked out, but that does not imply that this *should not* be done... And as for document specific toolbars, they should stick to their document, like IE has their image toolbar stick to it's image.

CC'ing MPT, who will no doubt have an opinion.

> 1) The fewer things that shift position when I open the Sidebar, the better. The fewer things that shift position when you change tabs, the better. People who use tabs change tabs far more often than they open and close the sidebar. And the entire content area already shifts position when you open the sidebar. If the Links toolbar were at the top of the content area, nothing would change in this regard. > 2) The links toolbar *is* a toolbar, correct? *Other* toolbars do not appear > below the tabs, why should this one be treated any differently? Because this one might appear and disappear depending on which tab is selected. Unlike the personal toolbar, the function of the buttons changes when you change document. I also just want to make it clear that no-one is envisaging having the toolbar scroll with the document. I thought this is what position:fixed meant - keeping it at the top of the viewport. As I said, there is a precedent for this - IE Mac's Auction Assistant. If you want a Links Sidebar, please go away and write one. You can even share the code we are using. This toolbar is not about to become a sidebar. Gerv

Are there any ways to have our cake and eat it too? I'm wondering whether we could somehow display as a toolbar if tabs aren't enabled, or inside the content frame of the tab if they are. People who don't have tabs enabled are likely to want a toolbar (because of the interaction with the sidebar); people who do are almost certain to want it in the content frame. Can we make everyone happy here?

Would it make sense to move the tab above all toolbars or at the bottom of the window? The links toolbar is not the only toolbar whose contents change when tabs are witvhed. The contents of the location bar also change when tabs are switched. (Placing the tabs at the bottom would be consistent with Composer.)

I want to make the position of the tabs configurable, since some people like them on top and some people like them on bottom. I am leaning towards having them on the bottom by default.

However, our decision should not be influenced by the default position of the tabs; if they can be at either position we need to consider both UI situations. We can't really have our cake and eat it too; imagine pressing Ctrl-T on a window with a toolbar. You'd get new tabs, the toolbar would move, moving the tabs upwards. Then about:blank would load and the toolbar would disappear. Ick. Let's not do morphing UI half-assedly; let's wait for proper reconfigurable toolbars, and stick with one location meantime. Gerv

One (possibly unpopular) idea: we could just disable the autoshow feature on the link toolbar and have it either always on or always off.

> If you want a Links Sidebar, please go away and write one. You can even share > the code we are using. This toolbar is not about to become a sidebar. > > Gerv I'd support link tag reflection in a sidebar panel. That seems to solve the several composability problems cited here nicely. Anyone up for it? Please cc: me on the bug. Has anyone considered making the toolbar float? It could then be per-frame (not just per-top-level window). The argument that this toolbar is not about to become a sidebar seems vacuous. This toolbar is not a done deal, and if it doesn't compose well with other parts of the UI (not just with tabbrowser), I don't think it should be kept as-is. A _fait accompli_ doesn't equal great UI, _pace_ those who have worked on various forms of the spec and patch for three years. Sorry if I'm preaching to the choir. IOW, what's the best form for this toolbar for all windows, not just the most expedient to integrate with a top-level/no-frameset-doc/no-tabbrowsers window? I'll happily continue this in m.ui if people are game. /be

> CC'ing MPT, who will no doubt have an opinion. Thanks ... The links provided by a document are part of the content of the document. Therefore the Links Bar should be part of the document. It makes no sense for two parts of the same document to be separated by chrome -- whether this chrome be one or more toolbars, or tabs, or whatever. So, if the links are for a page, they should appear at the top of the page. And if the links are for a frame, they should appear at the top of the frame. (They shouldn't scroll in either case.)

> The argument that this toolbar is not about to become a sidebar seems vacuous. I apologise if people seem short-tempered about this; for the last two years everyone who comes to this problem anew asks exactly the same questions. The reasons why it's not a sidebar are many, and have been done to death in the newsgroups and bug 87428 and bug 2800. I will review them here again: - If it were a sidebar, you would (in the vast majority of cases) have to either pop out the sidebar or change people's panel when you encountered a links page. This would be far more annoying than an auto-hiding toolbar. - Popping out the sidebar already has a bad rep. from search; it also causes the entire page to change shape, which adding the toolbar doesn't, and is therefore more intrusive - It would take up much more screen space. People will not leave the sidebar open just for this feature If <link> is to be adopted, the UI has to be such that people will, in the vast majority of cases, see it and not turn it off when they do. I still concur with mpt and others: this toolbar should be auto-showing by default, at the top of the content area, below the tabs if there are any. It should be notified using a custom DOM event so it appears before, or at the same time as, the content, so the content does not move. This is the best, most practical, and least intrusive UI and we should get there as quickly as is practicable. Gerv

Bug 103428 describes a temporary solution that would address the most annoying problem visible in this bug by making the toolbar stay visible as long as at least one current tab has links.

--> link toolbar

I agree with the idea that the links toolbar should be immediately above the document with no chrome between the document and the links toolbar (including the tab line). Furthermore, I propose that the links toolbar appear at the top of each frame for framesets.

I misunderstood the proposal when I posted my earlier comment. I agree with what Gerv (Gervase Markham 2001-10-05 18:57) says in the last paragraph. The <link> nav is the most closely tied to the page of any we have, so the UI should reflect that so we can get people to adopt this.

What about moving the toolbar into the status bar left of the the progressbar? Have it in a reduced form without any text so it hardly takes up any room. How does this idea sound/smell?

I'd rather have the link bar exactly where it is now. It think the tabs fit at the bottom better. (Not in the status bar but above/below it.)

/me agrees with Gerv Whether the tabs are at the top or bottom or are movable between the two, I think the links should be as close to the content as is practical. The visual style of the background of the tab bar, ie, very flat with a thin border, would seem to be appropriate to help people make the mental connection between the Site Nav Bar and the document, moreso than the current toolbar with its definate edge...

The site navigation bar should be a banner (as per the original in the HTML 2.0 specs when they were there) in the content area. It should not be scrolled away, so that it is available throughout the page. Add some preferences so that people can make the texts larger or smaller, and be done. People have discussed several reasons, but the most notable is that these links are thightly coupled with the viewed page and therefore should be shown as that. Then it is the point of frames, which I agree with, lets circumvent the problem which frames made for the location bar by doing this in a way where it is consistent. Furthermore, by incorporating this into the content area and making it a feature which is there when the site use it and not when not there (ie. auto show), it will be a feature which derivated gecko browsers would use as default also. As it stands today it seems to be a tack on which you would have to care about to implement, while it is a feature which should have been there back in the days of Mosaic (yes, I tried links in the header back then, as per the HTML 2.0 spec, IIRC). Making it position: fixed (ie. at the top of the screen all the time, think fixed background) will also serve the purpose of the nav bar, since it will be easily available throughout the page, and thus more useable than links interspersed in the text. I would also like to add that any problems in flickering between transitions is a moot point, since the flickering is just as visible in the site navigation bar today. When it comes to the sidebar (which isn't really part of this discussion, as far as I can see): it should be default on the left of the page for people reading left to right. The reason is that you usually move your eyes to the left to start reading, with the sidebar on the right the edge of the monitor/browser window, there is a more definite edge than the sidebar. Just try reading freshmeat.net vs a site with a lot of content on the left edge, personally I feel it easier to read freshmeat than many other sites just because the clutter is to the right end, termination of a line, instead of on the left.

> People have discussed several reasons, but the most notable is that these links > are thightly coupled with the viewed page and therefore should be shown as that. The link toolbar content is not the part of the chrome the most tightly coupled to the content, the URL box is (that where it shows the URL of the page beeing displayed - after all, links are only pointers to other pages, whereas the URL is the page itself). Another things that are more thightly coupled with the page itself than the link toolbar are the throbber and the progress meter. Therefore when a good solution to the interaction between the URL box, throbber, progress bar and the Tabs is found, the same solution should be used for the link toolbar. As the URL box is so tightly coupled to the page and want to make sure that people are aware of it, we should put it in below the tabs and even below the link toolbar. Actually, let's put it in the content frame itself. Same for throbber and progress meter. Same for the sidepannel. After all, the sidebar is just another web page, so it should have a URL box and a throbber (on my crummy 200MHz box, the search sidepannel would definitely deserve its own throbber :-(). Well, it seems that pure logic does not give good UI ;-) Maybe it's time for pragmatism. My feeling is that the main quality is the link toolbar is that it is *standard*, otherwise I would just put a fixed HTML frame on top of my pages (or at the bottom, or at the left - see http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link2.html for an example). If the link toolbar ends up to be something that could be done with a simple HTML frame in the page, then we have missed the point entirely. Therefore, the link toolbar should have standard placement, standard look, standard everything, and be as *integrated* in the browser as possible. Personally, I would like to put the link toolbar to the *right* of the personal toolbar : I've got only "home" and "Bookmarks" in it, so plenty of space wated for nothing (maybe it wouldn't if I was using Netscape branded version). Or even better, at the *left* of the personal toolbar, so that going from back/forward to prev/next minimise mouse movement while navigating complex documents ("save our wrists"). Also, I think that Tabs selection may want to be *above* the main navigation bar, just below the menu. That would seem more logical to me because all the content of the navigation bar apply only to the specific Tab beeing selected and is not generic to all Tabs. For example, when you press "Reload", you don't reload all the Tabs but only the one selected. But I also agree that it would not be very nice, so that's a tough call... And the sidepannel would also deserve to be on the *right* so it doesn't disturb my reading when it pops up, that we'll keep that rant for another day. Actually, if we don't keep things for post 1.0, we won't have anything reason to upgrade to 1.1 or 2.0... Alternatively, as we are supposed to be frozen towards 1.0 and minimising changes, I would vote (if voting matters) on completely disabling autoshow when there is Tabs (trivial fix). But that's probably to trivial and pragmatic as an end for such a nice discussion... Jean

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

As I understand it, this is the main bug preventing this feature from being enabled in Netscape builds. As such, and because I am told this is a serious design error with the current toolbar UI, I am changing the severity from enhancement to major.

Hixie, do you have a source for the claim that Netscape would turn the linktoolbar on if this were fixed? I know it's mpt's opinion that that's what they *should* do, but I've never had any confirmation from any Netscape people that it's what they *would* do. If this is confirmed truth, I may just have to increase my priority for working on this ;)

The only thing you can be certain of is that if it isn't, they won't :-) Believe me, this decision will probably be made by some marketing person no-one round here has ever met. The only thing you can do is make it as good as possible. Gerv

My source was hyatt, on #mozilla.

food for thought for whomever will ultimately be spec'ing the UI here. One problem with the current navigation toolbar which has not (that I read) been mentioned in the discussion here is that the popular (default, I think?) setting of "show only as needed" causes user errors in using the sidebar. Example: you've got a list of search results in a sidebar (or your daily websurf links or whatever). You're expecting to click each of at least a few of them in relatively rapid succession. Click, see if there's anything interesting, click the next one, look, click, look, click. This usage pattern is what makes the sidebar sohandy. Now suppose you teach yourself to be a bit more efficient. It takes time for a page to load, so you do this: click link, move mouse to hover over the next link. That way, as soon as the page loads, you can click the next link without having to "aim"... assuming the page isn't worth reading (as can often happen with searches on the web). This efficient habit is an easy thing for users to pick up, and I suspect (but have no evidence) that this use of sidebar links is somewhat common. Now, let the navigation toolbar enter the picture. As currently implemented, with the default settings, the toolbar will pop in and out of existance as needed. When it vanishes or reapears, the entire sidebar area gets rendered higher/lower by the height of the toolbar. This causes our poor efficient sidebar user to click in the wrong place. They were hovering over the "next link" as the page started to load. The page loaded, the navigation toolbar reapeared, their sidebar link was pushed down by the height of the toolbar, and when the user saw the rendered content and clicked what they thought was the "next link", their click was too high by the height of the toolbar. In accordance with the principle of least suprise, this should be adjudged a Bad Thing. I've got my nav toolbar set to always be there. This fixes things for me, but at the cost of some screen real estate. It would be nice if I could have the realestate back without the sidebar moving when the nav toolbar is not useful. (Also: many users will not be able to find the setting to always show the toolbar... two submenus is too deep for most users to discover.) For this reason, I would suggest layouts which place the nav toolbar in the following sorts of locations: 1) below tabs (when the tab area is around) in place of tabs (when it isn't around) 2) at the bottom of the window, either only as wide as the content, or perhaps as wide as the content+sidebars (the first sounds more attractive to me) You might think that "above the tabs" would work just as well as "below the tabs", but as has already been covered in this bug's discussion, doing so would cause the tabs area to jump up/down as the nav toolbar vanished/reapeared. This is no good for the sidebar, and it is no good for tabs either. Of the two options (three if you count the ugly variation of option #2), I prefer the option of placing the nav toolbar beneath the tabs. Some folks seem to gripe that this isn't how toolbars should behave. So be it. Don't call it a toolbar then. my 2 cents -matt

bug 104566 just got mentioned in my inbox. Any solution here should also consider the consequences of the tabs being on any of four sides of the content area unless that RFE gets WONTFIXed. -matt

adding self to cc list

Hixie wrote in comment #36: > because I am told this is a serious design error with the current toolbar UI Actually it is mainly a design error with the Tab-UI :-) One "solution" was comment #22 because it is actually an auto-show issue. But I wouldn't like this at all, using the auto-show toolbar (_and_ Tabs) all the time as a user myself. In all other cases I agree that directly upon the page's content was the best place. Not having read bugzilla for quite some time (sorry, RL is calling) I am still kind'a shocked that Bug 138496 was resolved but not Bug 119088 ... P.S.: Just for the record (I know that this is not this bug's topic) another reason why the sidepannel was not the right location for UI to the 'link'-Element: Most of the time I need them both! My sidepannel is either open with the 'CSS2 Quick Reference' or the 'Search'-Pannel. In both cases I need access to the standard-links of the found site but wouldn't swich pannels.

Stuart, how's this bug fitting in with your other priorities? The target milestone of 1.0.1 is outdated. Could you put in a new target? gracias :) -matt

Another option to consider :) What about the Mac button bar in MacOS 9 and lower. It has a docking handle at the left portion of the screen, and when you hover it, the bar appears, and disappears when it loses focus. When you click it it stays permanently at the top. This handle would be small, non-intrusive and cen be set top always shown, or always collapsed. (and maybe a perference to put it on the left or on the right). This could even be a small button on the tab, or an option available in the tab's context menu. So it would look like: ----------------------------------------------- |Tab name|Tab name|[Active tab]| X| |-----------------------------------------------| | Normal content of the page /| <- link handle | \| | | ----------------------------------------------- And with the tab visible: ----------------------------------------------- |Tab name|Tab name|[Active tab]| X| |-----------------------------------------------| |/ Top | up | first | prev etc | <- link bar |\______________________________________________| | Normal content of the page | -----------------------------------------------

Ok. So from a purely technical point of view, how would this work? Framesets are not done via chrome (that is, the splitters and such in frameset frames are not chrome). So I can't actually think of a reasonable (simple) way to put the link toolbar in a frme... Putting it inside the main content area should be a simple modification of the <tabbrowser> binding. The real stumbling block here seems to be that everyone is fixated on it being a "toolbar" and so having to live in a "toolbox", no? Why this fixation?

Forget frames. We don't need to support <link> in frames.

Heh, ummm... Unfortunately my other priorities (which these days include a new daughter) have almost completely superceded my ability to work on Mozilla at all. The only time I have to do any hacking at all is on the train, using a 486DX laptop with 4Mb that can't run X or any version of Windows greater than 3.1, let alone Mozilla, and trying to hack in that environment and test somewhere else later is all but impossible. So what I'm trying to say is, this patch needs someone else to pick it up, unfortunately. I wish the situation were different, but there you go :( I'm more than willing to give any assistance that I can through email, IRC or discussion in the bug to try to explain where I was headed with this patch and why it works (or fails to?) the way it does, or if someone wants to start again from scratch, any insight I can give into the issues you will encounter based on my experience working on the problem. Warning to anyone interested in doing this, though: you will become more familiar than you ever wanted to be with the inner workings of XUL and XBL and things like event firing order. You'll need to deal with nasty bootstrapping issues where you want to use something but can't afford to load the file that contains it. You'll need to deal with the fact that XBL is half unimplemented and that the spec doesn't give you the slightest hint as to which parts (and which parts have changed since the spec was written). You don't need to be an expert to start, but you do need to be willing and able to absorb quite a lot of knowledge about it. This is an optimization issue, after all, and so it's not something that can be done with superficial changes or superficial knowledge. Which is probably why I struggled so much.

Sorry, I was thinking of bug 102992 when I posted the last paragraph of the above - perhaps I'll paste it there. However, I think that bug ought to be solved before any work is begun on cosmetic issues like this one. Having said that, from a technical point of view I can give a possible solution. The linktoolbar would have to be put inside <tabbrowser>, or another "browser subclass" like <linktoolbarbrowser> would have to be implemented. The tabbrowser already places something above the content, so this code could be reused to put another element there. I lean towards the idea of putting it inside <tabbrowser> and activating it with something like <tabbrowser sitenav="true"/>. This would also allow the tabbrowser to put the sitenavbar *inside* each individual tab, so that bug 102905 would go away naturally. On the other hand, I do believe that bug 102992 should be solved first. Once the sitenavbar is implemented as an XBL binding, it would be much easier to simply "invoke" that binding inside <tabbrowser>, rather than having to pull all the code in, the way you do now.

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

retargeting

bz, what's the point of retargeting this bug back to v1.0.1? it has been over a year since this version was released. Prog.

prog: only the bug owner should change target milestones. (and priorities for that matter)

Attached is a mockup of site navigation bar - located on the right side of the menu bar. This may look odd at first, but can be very effective. Pros: 1. The displayed document and the tab bar do not "jump" when browsing pages that open the navbar (with the current implementation, they do) 2. More of the document is displayed, without wasting any screen real estate. Compared to this, both the current implementation and the one suggested by this RFE locate the navbar in a place where it reduces the display part of the window. Con: 1. Putting buttons on the menu bar is inconsistent with the UI conventions of any OS that I know. Notwithstanding that con, this irregular location is still self explanatory and easy to use. See the attached screenshot. Prog.

Con 2: it fails miserably on MacOS

Actually, it's probably just more difficult to implement on MacOS. If you align the Navigation Bar just to the right of the Help entry, you're still left with plenty of space between that and the icons at the right side of the menubar. Anyway, who said that everything must be implemented the same on all platforms? if the Mac has limitations, then there's just so much you can do. beisi, which approach would you prefer, and why? Prog.

> beisi, which approach would you prefer, and why? I'm happy with the site nav toolbar as it is...

Why can we forget frames? unlike the spiffy modern dom on http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link2.html mozilla is actually able to let me use the arrow keys on my keyboard to scroll frameset content. mind you, my framesets are very empty in the url example, but if they had content i /could/ scroll them with my keyboard. That said, is this still a major bug given that the vendor you were targetting is gone? -- Random thoughts. If the urlbar is really closely tied to the document, then why doesn't each frame in my frameset have its own urlbar? -- bz, about impl... suppose we hijacked <browser> or <iframe> by hoisting some xbl which lives there and reparents the real content the same way <tabbrowser> currently hijacks things... as for toolboxes to contain toolbars: they aren't required. however, toolbars look fairly ugly and don't behave very well when the container isn't present. as for the handle style and the os titlebar, just forget them. the former doesn't actually address any of the technical problems and the latter is both difficult even impractical on some platforms and absolutely beyond the scope of this bug "Site navigation toolbar should be *inside* content frame". People who do not wish to take my advice wrt forgetting the aformentioned suggestions are invited to take the following advice: file a new bug against yourself.

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

Any hope of this getting fixed? It's *still* a problem in 1.8a5. (And yes, I recognize it's free software and everybody has other stuff that's an issue as well, and all that... ;) And yes, the fact that if you have showlinks 'asNeeded', the Tab bar bounces up and down is the *SINGLE* *MOST* *ANNOYING* thing in the entire Mozilla UI, as far as I'm concerned. In particular, it means that I can't use "muscle memory" to find the little 'x' button to close the current tab, as it tends to bounce up and down along with the rest of the tab bar. It's particularly annoying if you use a Gtk2 theme that's a dark-background - that 'x' doesn't "pop out" at you when the background is #1f1f5f..

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614