currently the link toolbar does not work with frames. I'll attach a testcase. I think that the link toolbar should work with the relevant links in the frames. However the frameset document might have links too. I'm not sure how this need to be handled but without handling links in frames would make the link toolbar much less useful.

to gerv for triage.

This is a difficult question that it's not possible to answer immediately. When the initial hubbub around the links toolbar dies down, we can think about this issue. Bug 102990 is relevant - that will happen eventually, and will be a good start. If we can do tabs right, then we can think about frames. Gerv

back button doesn't support frames either. frames are a navigational hazard. may the guy who invented them have a dry, itchy scalp for all eternity.

Put LINK elements in your frameset document and the toolbar should work fine ;-) I'm only half joking. Frames are deprecated. How far must we go to support them? This bug could easily be renamed to "Frames make it hard to build consistent, easy to use navigation UIs". I vote for INVALID (per above frameset comment) or WONTFIX (per deprecation). Actually, I kind of lied that adding to the frameset would be enough, since I don't think we ever got the toolbar using the TARGET attribute of the LINK element.

WONTFIX. I probably won't fix this specifically. If it falls out of the tab work, so be it. Frames suck. Gerv

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

ok, I disagree with WONTFIX for the following reasons: Often frames are a. just redirections (like the one in the duped bug 105920) and the <link>-definition is in the content frame (the one with the "real" page) and if you follow a link on this site, the <link>-elements also change and they can't be defined in the frameset b. there is one navigation-frame in which the <link>-definition is done. This frame can change too, e.g. for different sections of the website and so the <link>-elements can change, too and they can't be defined in the frameset. And if there are <link>-Tags in the frameset AND one or more frames of the frameset, it's still easy to decide which should appear in the site navigation bar: 1. you use the ones defined in the frameset 2. then you start searching for them in frame[1], frame[2], .., frame[n] and mozilla adds new <link>s respectively overwrites existing ones of the frameset or previous frames. Any objections?

WONTFIX === extraordinarily low priority compared to other links toolbar stuff. So low, in fact, that anyone who has the skill to work on it should be working on more important stuff for 1.0. If you want to reopen it, assign it to nobody@mozilla.org, and target it at Mozilla 1.2, feel free. :-) Gerv

ok here goes

I would understand your comment, if it had been on a feature request, but this bug is just the full functionality of a yet-implemented feature! Many pages use frames and additionaly there are thousands of redirections managed with frames, especially on personal websites. It's not a bug which affects one or two pages and if you want people to use <link>-Tags they have to be able to use them in frames, too, since it is an additional way to navigate through pages and not an alternative to a frame-based navigation!

and so that Gerv wouldn't hear about this bug again

sorry for the spam: your == Gervase's

I repeat: I would implore anyone who has the skill and knowledge to be working on this to work on e.g. XBLifying the toolbar, or moving it into the content area, or fixings its performance problems, all of which are higher priority than this. Some of them are prerequisites, as well. Gerv

Niko: I think more thought is needed before attempting to fix this. We should see how other browsers handle this (if at all). I originally thought that this could be fixed by having the link toolbar correspond to the currently focused frame, but I realized that it is not always ideal. Maybe something like having the link toolbar correspond to the currently focused frame and if it does not have (some of the) links, display the links in the parent and so on and so forth... This is just an idea, why don't you bring this discussion to a mozilla newsgroup like netscape.public.mozilla.browser and maybe some web developers mailing list/newsgroup or even the W3C HTML mailing list and see what they say about how links and frames should be handled (note that frames include both framesets and iframes)

When/if bug 102990 is fixed then I assume it would be possible to put a Site Navigation Bar (or whatever we're calling it nowadays) in each frame. I have no idea what to do about the case where you have both a frameset and frames with <link> tags though. And don't even begin to confuse my little mind with the possibilites of nested framesets... So how do browsers like iCab do this?

ok, I thought about the problem, again. Here's my new solution proposal: After the toolbar is placed above the content area with bug #102990, the toolbar should show the <link>s of the currently selected (focused) frame. It is not a good idea to place a toolbar in each frame, which has <link>s specified, since frames are 1. often used as an layout element and the layout would look like **** with a toolbar in it. 2. often very small (100 - 200px), especially navigation frames, which probably have the <link>s specified in the most cases.

Good idea, but it doesn't solve the problem of if the frameset document has <link> elements though.

This thread gives another proove of the general weakness of the frames concept. One of the main weaknesses of frames in user experience is that viewable content is no more directly connected to the URL in the URL bar. At least the link navigation toolbar needs to keep this connection. The values of <link ...> can only be displayed for the topmost frameset. Everything else would give a user experience desaster. Having an own link toolbar for each frame is no solution for several reasons: * Most sites use frames mainly for decorative reasons. Webmasters do weired things to make frame borders invisable to their users. I think that this is a bad idea, but _they_ would hate us for setting tolbars in the middle of what they call "their layout" * There is still the option for displaying the toolbar always. Imagine what this would do to sites that use 4 frames only to create a margin around the content! * The basic idea in navigation by the link element is standardisation. It has to be consistent for all sites. Thus there can be only one link toolbar at a time and it has to keep its place inside the crome. (Please reread <http://www.euronet.nl/~tekelenb/WWW/LINK/> for the basic idea!) BTW.: The toolbar's place should be either as near as possible to the site content or it should be connected with the page title and the URL bar. * Compare! Where is the content of title element of framed pages displayed? * Try to think a frameset document to be a normal page that references external data (like Images and iframes), only with the difference that the external data takes 100% of the viewport! Would you as well like a toolbar and a title for each iframe? More about frames (sorry, only in German): <http://www.subotnik.net/html/frames.html> More about the link element (sorry, some weeks outdated concerning browsers): <http://www.subotnik.net/html/link.html> IMO Mozilla already behaves correctly concerning <link ...> in framed situations. It uses those in the topmost frameset (Example: <http://www.buhev.de/aktuell.html>) Ergo: --> invalid

I'd like to add my vote that we WONTFIX this. Let's not encourage authors to use frames any more than they need to.

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

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420