Open Bug 102990 Opened 18 years ago Updated 6 years ago

Site navigation toolbar should be inside content frame

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: jesse.houwing, Unassigned)

References

()

Details

(Whiteboard: [Hixie-P0][Hixie-P1])

Attachments

(1 file)

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
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [RFE} Links toolbar IN tab, instead of in Main toolbar. → [RFE] Links toolbar IN tab, instead of in Main toolbar.
Hey, I really like this idea. It makes a lot of sense.

Status: NEW → ASSIGNED
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.
Blocks: 103053
Summary: [RFE] Links toolbar IN tab, instead of in Main toolbar. → [RFE] Links toolbar IN tab/frame, instead of in Main toolbar.
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
Summary: [RFE] Links toolbar IN tab/frame, instead of in Main toolbar. → 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.
Target Milestone: --- → mozilla1.0
--> link toolbar
Assignee: hyatt → sballard
Status: ASSIGNED → NEW
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.
Summary: Links toolbar should be inside content frame → Site navigation toolbar should be inside content frame
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
OS: Windows 2000 → All
Hardware: PC → All
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.
Severity: enhancement → major
Whiteboard: [Hixie-P0][Hixie-P1]
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
Blocks: 103417
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
Target Milestone: mozilla1.0.1 → Future
Target Milestone: Future → mozilla1.0.1
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 image An alternative approach
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...
Severity: major → enhancement
Target Milestone: mozilla1.0.1 → ---
Assignee: sballard → tabbed-browser
QA Contact: blake → nobody
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..
Product: Core → SeaMonkey
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
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.