When a window is showing a valid URL, there should be a proxy icon in the titlebar, representing that URL. The proxy icon should then be draggable as a URL clipping to the desktop, another Navigator window, or the bookmark drawer. If the window has multiple tabs in it, only the active tab's URL should be represented as an icon, just like only the active tab is represented in the title. Advantage? URL manipulation without the necessity for the toolbar. Parity with IE and OW.
See also Mozilla equivalent bug 36305. Should we duplicate the icon shown in the Location field, or just move it completely to the title bar?
Status: UNCONFIRMED → NEW
Ever confirmed: true
and of course also the proxy icon should act like in textedit and ms word with local files (ie, point to directories in the HD)....
The bug 175470 is about adding a menu to the window title.
The icon must be in both because the Location is not always visible. See Bug 184030 - single page: same proxy/fav-icon in Location field and Title bar - multiple pages (tabs): proxy/fav-icon in Location field and a multi-pages icon in the Title bar. Multi-pages icon can be seen in the Bookmarks/Sidebar if you add a bookmark for a tabbed window with all tabs. That will be more consistent everywhere: Windows, Tabs, Bookmarks, Sidebar. See also Bug 159510 note 23: The Window menu in the menubar can be hierarchical, with a Right Triangle to show the submenu with all its 'tabs'. For the main title in the Window menu, the current 'tab' name is used, just add a submenu to its right with a checkmark in front of the current 'tab', itself. That means in first level it will be proxy/fav-icon for single page window and multi-pages icon for tabbed windows, the second level (tabs) menus always with proxy/fav-icon.
This has been fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
(In reply to comment #5) > This has been fixed. Please give a build. I do not see an in the title bar in a recent nightly.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> (In reply to comment #5) > > This has been fixed. > > Please give a build. I do not see an in the title bar in a recent nightly. This is a bug about the fav-icon being implemented from 2002. I has since been implemented. If you're having trouble seeing it, it's probably an issue with the most recent nightlies that will be fix. Am I wrong?(In reply to comment #6)
Oh. NM. This is about the titlebar. Wow, missed that for some reason. I sugguest a WONTFIX for this. No other Mac browser has it and it would crowd the title bar too much.
OmniWeb, Internet Explorer an Opera all have this functionality.
First off, depsite Internet Explorer running on a Mac, it never truly became a "mac product" and integrated with the OS, so let's discount that for a minute. Now, let's move to the HIG. http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_8_section_3.html#//apple_ref/doc/uid/20000961/TPXREF10 The link above discusses proxy icons in the title bar, probably the relavent information for this bug. ;) As discussed on the page, the proxy icon is to appear after a document has been saved for the first time. Camino doesn't really do "saving". No web browsers truly do. We do save webpages, but it doesn't apply to the concept of standard save and open in Mac OS X. The functionality received in the proxy icon isn't important to Camino as we still have it preserved in the title bar as well as tab bar (when shown). The other mentioned applications have proxy icons in their title bars for other reasons. If tabbed browsing is not functional in the browser (or implemented an entirely different way, as in OmniWeb), there is only ever one proxy icon displayed at once. This isn't true for Camino. By displaying it in tabs, we keep it as part of the window and and allow the user to discern between sites with it. One can argue that we could move it from the location bar to the title bar, but it's not appropriate in this case. I would argue that if you want to remove it from the location bar, it should be removed completely when tabs are showing and appear again when they aren't. Finally, if a document is called "Untitled" or something similar, or any name that is generic, the user has no idea what "url" he his looking at without checking the location bar. By putting the proxy icon next the the address we give the user a point of reference, something that stands out, that they can focus on to see the location. The title can be completely random and not help one bit in discerning between sites. Think of phishing. We want the user to check the location bar more often than they check the title bar. Titles can be deceptive, URLs cannot (well, they can right now, but not after bug fixes are made to prevent phishing). Again, I suggest WONTFIX.
I recant. I like the idea, despite it's lack of usefulness. :) However, following the HIG, we shouldn't do this. It's all a preference. One major issue I see is with favicons with "white" backgrounds. They'll look off and fairly ugly should we implement this. Same with other sudo-transparent icons. Jasper, any thoughts on design? Wevah, on implementation?
(In reply to comment #11) > I recant. I like the idea, despite it's lack of usefulness. :) However, > following the HIG, we shouldn't do this. It's all a preference. > > One major issue I see is with favicons with "white" backgrounds. They'll look > off and fairly ugly should we implement this. Same with other sudo-transparent > icons. The way IE did it was to ignore the favicon altogether and just put some little IE-only symbol (equivalent to the globe) up there. Its only use, so far as I can tell, is in bookmarking/webloc'ing/dragging, which are already coverd in Camino via the Location Bar and on the Tab widget itself. No other Mac browser the favicon there, it's redundant and has no purpose other than its redundancy, (and frankly I don't find it visually appealing) and, since the window is not a real document in the traditional sense and is neither local nor saved, there shouldn't be any sort of icon according to the AHIG. Samuel's arguments in comment 10 are more convincing than those in comment 11. I recommend this (again) be WONTFIXed. There are more important fish to fry.
And it's *really difficult* to implement properly.
How odd that I haven't commented on this bug yet. I think this bug should be WONTFIXED.The functionality of this proposal is covered by several other UI elements such as the url bar and the tab bar, as mentioned. The only usefull thing we could do with the title bar is do what Safari does when command clicking on it, which is shwoing the url structure of the website, but I think that is covered by an other bug.
Well, since no one did it and we more or less agree... WONTFIXing.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.