1703342 - need page download date-time

Status: RESOLVED DUPLICATE of bug 1734924

(Firefox :: Page Info Window, enhancement)

Description

[Nick Levinson]

STR:

1. Open a Web page.
2. Go to Tools > Page Info > General > Modified.
3. Notice the time.
4. Close the Page Info window.
5. Again, go to Tools > Page Info > General > Modified.

Actual result:

This shows the time the Page Info window was opened, which is, I think, useless.

FF version 87.0 (64-bit). Fedora 33 Linux, kept evergreen.

Expected result:

Show when the page was downloaded, either when it began or when it finished. Probably when it began is better, because it could take minutes (hypothetically hours?) to download an entire page with many elements from remote servers and redirection and long latency, and only giving when it finished would mean not giving any info until finishing can be determined, which might be complicated.

The usefulness is that I often have to state somewhere the date I accessed the page, I may work overnight, and I may not remember if I accessed the page before or after midnight.

Comment 1

[Nick Levinson]

I since found bug 1120649 and bug 1196500. The Modified field serves another purpose and is not a date-time stamp for when FF received and rendered the page.

However, we need that date-time stamp. So, instead of this being a bug report, it has become an enhancement request.

The treatment of pages previously rendered and since closed when the closing of the tab is undone would generally be to assign a new date-time stamp because the Undo Close Tab (in my observation) causes FF to go out to the location (often on the Internet) to retrieve a fresh copy.

However, if the page is re-rendered from a Firefox cache, then the date-time stamp should be for when the page was rendered before caching.

Comment 2

[Timea Cernea [:tbabos][inactive]]

Hi Nick,
Thanks for the enhancement request! Will mark it as New and we are already in the correct component here so developers will take a look at it.

Comment 3

[A.D.F.]

I think this bug is not exactly an enhancement but a real "defect" because window field "Modified:" should refer to the "Last-Modified:" HTTP response header.

As stated by RFC 7232, this "Last-Modified:" HTTP header should always be present in HTTP/1.1 and later versions, even if there is an "ETag:" header.

"Last-Modified:" header exists since HTTP/1.0 so the following criteria could be adopted (just a few hints):

1. if a "Last-Modified:" HTTP header was found in server response for the web page then use that value in "Modified:" date time;
2. if a "Last-Modified:" HTTP header was NOT found in server response then use a placeholder like: "Unknown" (or something like that) as date time value;
3. it might be useful to rename the window field from "Modified:" to "Last Modified:" to remark the fact that it comes from HTTP server response;
4. add a new window field named "Retrieved:" using date and time of when the web page was retrieved (maybe the completion date time of the network response of the web page or something like that).

Comment 4

[A.D.F.]

See also bug 1734924 (more complete information about the topic with a few proposals).