103704 - Page Info: More info and navigable links

Status: RESOLVED WORKSFORME

(SeaMonkey :: Page Info, enhancement)

Description

[Robert Crews]

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.

Comment 1

[Christopher Hoess (gone)]

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; [e-mail] does most of the work on that feature.

Comment 2

[Robert Crews]

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.

Comment 3

[Christopher Hoess (gone)]

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.

Comment 4

[Robert Crews]

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.

Comment 5

[Robert Crews]

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'.

Comment 6

[Dan Tobias]

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"!

Comment 7

[Christopher Hoess (gone)]

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.)

Comment 8

[Daniel Brooks [:db48x]]

I should be able to get to all of these by the time 1.1 is released.

Comment 9

[R.K.Aa.]

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

Comment 10

[gabriel]

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.

Comment 11

[Boris 'pi' Piwinger]

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

Comment 12

[Bill Mason]

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

Comment 13

[Boris 'pi' Piwinger]

Any news on this? Target milestone is in the past.

pi

Comment 14

[Jesiah S]

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

Comment 15

[:aceman]

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.

Comment 16

[Philip Chee]

Currently the links in the Links Tab are copyable, but not clickable. I think that this is enough to close the bug as WFM.

Comment 17

[Brian Lalonde]

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?