Closed Bug 103704 Opened 18 years ago Closed 11 years ago
Page Info: More info and navigable links
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20011008 BuildID: 2001100803 According to the HTML 4.01 recommendation (<http://www.w3.org/TR/html4/struct/global.html#h-7.4.1>), the links in the head element, for which the Links Bar provides an interface, can be defined by the profile attribute of the head element. In order to be a complete implementation, the Links Bar should provide links to the URI or URIs identified in that attribute. More information about these profiles can be found at <http://www.w3.org/TR/html4/struct/global.html#profiles>. Reproducible: Always Steps to Reproduce: 1. Turn on the links bar. 2. Go to <http://www.virage.com/>. 3. Note that there is no link to <http://www.virage.com/metadata.html>, which is identified as the metadata profile in the profile attribute of the head element. Actual Results: There is no GUI to provide a link to the metadata profile. Expected Results: A link to the metadata profile. In addition to the links in the head element, the View Page Info should provide a GUI for the text information provided in the head element, such as author, description, keywords, etc. I've been thinking about opening a separate bug on this, but I haven't had time to think about what component I should assign it to.
I'll take this, but there'll probably have to be some UI consultation on how to access the profile. (Admittedly, this isn't very high priority, either, given that I don't generally see profiles used in practice). If you're looking for information on Page Info, I think bug 57230 is a focal point for work; firstname.lastname@example.org does most of the work on that feature.
Assignee: blakeross → choess
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
QA Contact: sairuh → claudius
Target Milestone: --- → Future
I made a mistake in associating this with the Link Bar. The Link Bar UI is simple and useful just the way it is. I should have associated my concern with the Page Info component, as I've been meaning to do for some time. The Page Info dialog box should provide links and text for: head profile script src link rel (href) img alt (src) (longdesc) a title (href) meta name content scheme I think it is fine that link element information gets into both components since the Link Bar is for navigation and the Page Info dialog box is for ... well, page information. You are correct to point out that few people use the profile attribute in practice, but just like was suggested for the Link Bar itself, if there was a supporting UI, maybe more people would use these very cool features of HTML. Sorry for my confusion. This should not block bug 103053. I'm willing to withdraw this bug until I think through the issues more.
No, you're correct, Page Info should provide access to all that metadata. I'll reassign this to db48x and let him connect it to his meta-bug. I spoke a bit hastily when I said "many sites don't use it"; while this is true, and your counterpoint also is true, the real problem is that it's not clear there's every been substantial work done on establishing a format for such profiles, without which they're not very useful. Maybe some RDF people actually have gotten around to that; I'll keep a cc on here in case anything useful to the toolbar turns up.
Assignee: choess → db48x
No longer blocks: 103053
Summary: Links Bar: Need support for head profile attribute → Page Info: Need support for head profile attribute
Thanks for the encouragement. Here's what I'd like to see the Page Info dialog box look like.... A tabbed pane, like it is currently. The first tab should be labeled "Scheme"; alternately, it can be labeled dynamically with the name of the scheme. If the scheme is HTTP, then the tab should display the HTTP response header as a table of names and values. If HTTPS, add the encryption level. If the content is HTML (text/html or application/html+xml, or text/xml or application/xml with post-processing), then the pane should also display the content of meta elements with http-equiv attributes. These values should be displayed separately from the actual values from the HTTP response headers. If other applications have an equivalent to http-equiv, then they would display here as well when their content is received. There should be similar information for other schemes: FTP (login name, binary or text transfer mode), etc. The next tab should be labeled "File"... or "General" or "Data." This tab should show information about the file: the file size and URL. The file size plus the size of the HTTP response header should be shown in parentheses. (A table of download times at common network speeds would be cool here.) Some of this information comes from the HTTP response header, but it's OK to reproduce it here. Then, if known, much more about the file: Binary? Text? If text, the character encoding, number of lines, words, characters. If XML, number of elements, number of attributes. If an image, the real width and height of the image (not the width and height from the HTML markup), the DPI, if applicable. Note that the word count would be different for text/plain than for the same file as text/xml since the word count for XML should only count words in PCDATA or CDATA. As an example, assume a file is sent to the browser with a MIME type of application/octet-stream, but the first six characters are 'gif89a'. In this case, the Scheme tab will display the MIME type from the HTTP response header, but the File tab will display the file type as GIF89a. If the content is a known format, then the File tab should show metadata parsed from the file. For HTML, that'd be title, meta elements containing nonlink values, etc. The next tab should be called "Links," and it's purpose is to provide information about -- and live links for -- all the links in the document, including a live link to the document itself. For HTML, these links come from at least the following: head profile script src link rel (href) img alt (src) (longdesc) a title (href) meta name content scheme No preview like currently exists in the Images tab is necesary. Because these are all live links, clicking them displays the referenced data in a real browser window. Then, if desired, Page Info can be called again on that content. (By the way, this is what a very cool MacOS-only application called Anarchy does. With that application, I can browse the internet with each page represented as nothing more than a page of links. (A new spin on browsing with images off!) Very fast... And very, very cool. Unfortunately Anarchy does not support cookies, so browsing https sites is nearly impossible. Mozilla can do better.) So the Links tab should have a check box for link browsing: if checked, clicking a link does not present the referred-to data in a browser window. Instead, it just parses the links and updates the current Links tab with links from the new document. Remember that there's always a link to the current document in the list of links, so to see the current page rendered in a browser, you just have to click the link for the currently parsed page. I like the Forms and Security tabs. I wouldn't have thought of those. The Forms tab should be expanded to show all their form elements, each associated with their name, id, and default value. Possible valus for select boxes can be shown as a comma-separated list.
Here's a more complete list of HTML attributes that take URI values: a href | input src applet code | input usemap applet codebase | ins site area href | img longdesc base href | img src blockquote cite | img usemap body background | link href del cite | object archive form action | object classid frame longdesc | object codebase frame src | object data head profile | object usemap html version | param valuetype iframe longdesc | q cite iframe src | script src The idea is that on the link tab, o single-clicking a link downloads the new content, parses it, and displays the links (if any) in the existing link tab pane o single-clicking the current-page link displays the "current" page in a browser window as if the link was chosen from the URL bar o right-clicking (or whatever the appropriate platform convention is) brings up the standard right-click menu that allows users to download the content to a file, copy the link, etc. I changed the title of this bug to be more representative of what it's about. I changed the priority from 'P5' to '--'. I changed the severity from 'trivial' to 'enhancement'.
Severity: trivial → enhancement
Priority: P5 → --
Summary: Page Info: Need support for head profile attribute → [RFE] Page Info: More info and navigable links
I'll second the comments here in favor of having a rich, sophisticated "View Page Info" function giving all available "metadata" about the current document. The current Mozilla "View Page Info" is in some ways still inferior to that of Netscape 4.x (for instance, it doesn't show the MIME type and charset parameter of the current document). If all the items suggested in this entry are implemented, Mozilla would really become the premier "Computer Geek Browser"!
Component: XP Apps: GUI Features → Page Info
QA Contact: claudius → pmac
Just to drop a few more ideas in here: we could also use the "type", "hreflang", and "charset" attributes of <a> and <link>, and the "type" attribute of <object>, to make a first guess at content-type and language. A somewhat more risky extension would be to make HTTP HEAD requests for all media and links on the page, which would allow us to display a range of HTTP-delivered information (possibly including Content-Type/charset, language, size (from Content-Length), and possibly additional information as well. (Remember, of course, that this would be shown for all external resources on the page; we probably don't want to dump every header resulting from such a request, although we should also be implementing some view that lets you see the full underlying HTTP transaction -- I'm pretty sure there's already a bug filed on this.)
I should be able to get to all of these by the time 1.1 is released.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.1beta
*** Bug 141712 has been marked as a duplicate of this bug. ***
It would be nice to be able to save all the links from a page as an html file as well, similar to the way bookmarks.html does it.
*** Bug 146397 has been marked as a duplicate of this bug. ***
*** Bug 154033 has been marked as a duplicate of this bug. ***
Any news on this? Target milestone is in the past. pi
Summary: [RFE] Page Info: More info and navigable links → Page Info: More info and navigable links
*** Bug 230524 has been marked as a duplicate of this bug. ***
I would really like that right-click menu on the links, which would allow to save or view the referenced files. Currently, in 1.7b, those links are dead, they can't even be copied to the clipboard.
Status: ASSIGNED → NEW
Priority: P2 → --
QA Contact: pmac
Target Milestone: mozilla1.1beta → ---
Currently the links in the Links Tab are copyable, but not clickable. I think that this is enough to close the bug as WFM.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Should bug 230524 be re-opened then, since it is more specific about "navigable" in that it requests Open and Save As context menu items for the links?
You need to log in before you can comment on or make changes to this bug.