Make title line similar to other lines



Page Info
13 years ago
10 years ago


(Reporter: David E. Ross, Unassigned)



Firefox Tracking Flags

(Not tracked)





13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.10) Gecko/20050716
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.10) Gecko/20050716

On the General tab of the Page Info window, the first line (the title line)
should be formatted similarly to the other lines, with "Title:", some spaces,
and then the page title.  Currently, this line has no designation, and the page
title ends in a colon.  

For all the other lines, I can mark and copy the values without any problem. 
However, for the page title, the copy includes the colon, which I must then
manually remove when I paste the value in a document.  

Reproducible: Always

Steps to Reproduce:
1.  Go to the cited URL.  
2.  On the menu bar, select View > Page Info.  
3.  Open a blank text editing window.  
4.  Mark and copy the first line (above the URL) from the Page Info window.  
5.  Paste into the text editing window.  
6.  Repeat steps 4 and 5 for the value following "Modified:".  

Actual Results:  
The title ends with a colon.  The modification date does not end with a colon.  

Expected Results:  
All copied values should be without colons unless colons explicitly appear in
the HTTP headers.  

The appearance of a colon at the end of a title was originally reported as an
error in bug 299764.  The assignee (Daniel Brooks) marked it as WONTFIX because
the colon is inherent in the design of the Page Info window.  Rather than
overhaul that earlier bug report into an RFE, I am submitting a new bug report.  

Note that this might also apply to Firefox.
The title isn't specified in the HTTP headers, so why should that spec come into
play? Still, I know what you mean. It should also be pointed out (for
completeness sake) that none of the other data on that tab is presented exactly
as it was in the original transaction. Even things like the expiration time is
not the expiration given in the HTTP headers, but when the document will
actually expire from the Firefox cache, which can be completely different. This
is probably a bug, since it's not what most people expect, and has been filed as

Now, on to possible solutions.

As much as it gratifies me to see people using software that I wrote, even
something as simple as Page Info, might I suggest that manually copying data
from page info to another document is almost as bad as retyping that info? It's
quicker, sure, but it's still manual. Computers are supposed to free us of the
manual drudge work, allowing us to be creatures entirely of the mind.

With that in mind, perhaps what you really want to do is create a javascript
bookmarklet that stuffs the data you need into the clipboard for you. You could
load a page in the browser, click on the bookmarklet in the bookmarks toolbar
and then paste in your word processor (or wherever). You could even write an
extension that does this creates a new file for every web page you view with
whatever info you need. 

This is how computing was meant to be: the programmers writing the basic
functionality, and the users writing programs that combined those functions
together in unique and imaginative ways.

Besides, what better way to minimize errors and prevent budget overruns than to
improve your life-cycle methods! Sorry, I'm in a weird mood today, and
everything seems especially surreal.

If you want, I'll even help you get started with your bookmarklet. I just don't
particularly want to change the way this part of Page Info looks.

Comment 2

13 years ago
As a software professional for over 40 years (over 30 years as a software test
engineer and now retired for 2 years), I long ago learned not to bother
automating simple tasks (mark, copy, paste) that I do only once or twice a
month.  The effort saved will never equal the effort in coding, testing, and

A bookmarklet might solve the problem for me, but it won't help anyone else
without multiplying the effort by the number of users.  

In any case, while I know a number of software languages (including a number of
"dead" ones), JavaScript is not one of them.  If you want to do the whole thing,
thank you.  If you want merely to start it, I won't be able to finish.  
Hm. I'm not sure this enhancement is worth coding, considering that:
- you can select the title without the colon
- you can use View Source (Ctrl+U) and select there whatever is included between <title> and </title>

OK, let's bump the hot potato upstairs. Does anyone "in power" say this bug should be kept open? If not, resolve WONTFIX.

Comment 4

10 years ago
Consistency for the General tab in the Page Info window is a usability issue.  

On the General tab of the Info window, I can triple left-click on a field to select the entire value.  Then I right-click to get a pull-down context menu from which I can copy the selected text.  This works except for the page title.  

For the page title, a triple left-click highlights the field -- including the colon at the end, which is not really part of the title coded in the <Title> element of the page.  If I wish to report something about the page while citing the page's title and URL, I have no problem with the URL.  To report the title, however, I have the following options:  

1.  Report the title, not as coded but with the colon.  This extraneous punctuation may cause problems depending on the context in which the title is being reported.  (This is how I originally discovered this problem.)  

2.  Copy and then manually edit the title to remove the colon.  See #3; positioning the cursor at the colon is also cumbersome for me.  

3.  Manually sweep my cursor over the title, stopping short of the colon, and then copy.  As I type this comment, I have a splint on my right hand to immobilize my thumb; I am very much right-handed.  Without the splint, my thumb is exceedingly painful.  Sweeping a cursor to include the last character in a field but excluding the very thin colon just after that character is difficult for me.  Perhaps, this is even an ADA issue; I wonder how well a user with Parkenson's (my wife, for example) might handle this.  

Ah, yes, I see now how this can be a problem for users with limited mobility.
Ever confirmed: true
Keywords: access
Assignee: db48x → nobody
QA Contact: page-info
You need to log in before you can comment on or make changes to this bug.