Whyever this bug hasn't been filed during the past 9 years...

Why should it be an error page rather than a dialog? For resubmitting a Bugzilla query, there's nothing erroneous about it.

Yeah, "error" doesn't quite cut it - but the principle should be the same, just display a friendly information bubble instead of the warning triangle.

When I hit the POSTDATA dialog, I'm often trying to get back to the page with the POST form. Switching to an information page would fix that :)

I mostly want something that won't stop me from hitting 'back' again (or 'forward' after); it should also say why it can't just show the previous result (as bug #493438). What I'd really like is an info bar across the top of pages in the history with buttons for 'refresh' and/or (when appropriate) 'resend' (for "and" see bug #322984) (It'd be especially nice if using those buttons didn't clear the forward history) This also relates to Bug #288462 about when data is requested from the server, to Bug #28586 about info pages, and to Bug #123913 about avoiding modal alerts.

This approach is problematic: If you're on a page which is a POST response, and you don't know it's a post response, when you hit reload your page will be replaced with an info page. How do you get back to the original page? Reload isn't expected to change the target of the Back button. With a dialog it's trivial: hit cancel.

Scenario: I have pages X and Y in the history (in that order) and the page X is a POST response and my current page is Y. If I hit back button, I should see the X page from the history (even if the page is expired, see HTTP RFC and history mechanism). Hitting a reload should replace the X page (in content area) with an info page that contains message saying that reloading the page from the server requires sending the POST again, which may cause side-effects. After the message, there should be TWO buttons: "Reload from server" and "Reload from cache".

This patch (or a bitrotted version) received r=bz in bug 160144. However I attached it to the wrong bug by mistake and it actually belongs here, because bug 160144 covers all sorts of other cases that aren't relevant here. In particular, this bug is only about a deliberate history navigation action to a page that could not be retrieved from the cache. As such, I have basically copied the wording from the existing dialog. It is the exact text of this wording that I am seeking ui-review for. In particular, I would appreciate that if ui-review is denied then the exact correct wording for a) the "error" document page title (notCached.title), b) the in-page heading (notCached=) and c) the in-page description (notCached.longDesc) should be provided. Discussion as to whether the action should have tried to retrieve this page or whether the page should have been found in the cache or elsewhere is not relevant here.

Can you attach a screenshot of the UI and req

sorry (submitted by accident) can you attach a screenshot of the UI and request ui-review on that?

This screenshot shows the page that you get when you navigate, plus it shows that clicking Reload or Try Again still presents the POSTDATA prompt, which is bug 160144.

Comment on attachment 566396 [details] Screen shot thanks small nit: perhaps "re-request" instead of "rerequest" otherwise ui-review+

Isn't this intended for navigating the session history? If that's so, why does the message refer to the cache rather than the session history? I would expect something more like this: The content of this page is not available in the session history • This page was a response to a form submitted to the server; As a security precaution, Firefox does not automatically re-sumbit forms. • Click Try Again to re-submit the form — this may repeat any action (such as a payment or search) that was performed earlier.

the UI doesn't need to accurately represent what is happening at an implementation level. In this case "cache" works better as a generic sense of "things stored by Firefox" or "try clearing your cache." Cache is of course still pretty jargony, but in the user's mind "session history" is a set of tabs, since that's how we frame restoring a set of tabs in the UI.

Pushed changeset 1354c0187053 to mozilla-central.

Comment on attachment 566065 [details] [diff] [review] Proposed patch >+<!ENTITY notCached.title "Document Expired"> >+<!ENTITY notCached.longDesc "<p>The requested document is not available in Firefox's cache.</p><ul><li>As a security precuation, Firefox does not automatically rerequest sensitive documents.</li><li>Click Try Again to rerequest the document from the website.</li></ul>"> s/Firefox/&brandShortName;/

(In reply to Reed Loden [:reed] (very busy) from comment #15) > Comment on attachment 566065 [details] [diff] [review] [diff] [details] [review] > Proposed patch > > >+<!ENTITY notCached.title "Document Expired"> > >+<!ENTITY notCached.longDesc "<p>The requested document is not available in Firefox's cache.</p><ul><li>As a security precuation, Firefox does not automatically rerequest sensitive documents.</li><li>Click Try Again to rerequest the document from the website.</li></ul>"> > > s/Firefox/&brandShortName;/ File a new bug please?

(In reply to Reed Loden [:reed] (very busy) from comment #15) > s/Firefox/&brandShortName;/ I don't know if a new bug has been filed as requested in comment #16 but there is also a typo in this line: s/precuation/precaution/

(In reply to Ehsan Akhgari from comment #16) > (In reply to Reed Loden from comment #15) > > (From update of attachment 566065 [details] [diff] [review]) > > >+<!ENTITY notCached.title "Document Expired"> > > >+<!ENTITY notCached.longDesc "<p>The requested document is not available in Firefox's cache.</p><ul><li>As a security precuation, Firefox does not automatically rerequest sensitive documents.</li><li>Click Try Again to rerequest the document from the website.</li></ul>"> > > s/Firefox/&brandShortName;/ > File a new bug please? I was copying file style which is to use Firefox literally. (This is after all a Firefox-specific file.) We don't import brand.dtd so it wouldn't work anyway.

Oh, I see now, it got added after the initial version of the patch.

No, wait, I was looking at the properties file, which isn't branded...

(In reply to Benoit from comment #17) > there is also a typo in this line: > > s/precuation/precaution/ Bug 694397?

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #13) > the UI doesn't need to accurately represent what is happening at an > implementation level. In this case "cache" works better as a generic sense > of "things stored by Firefox" Considering the amount of confusion about this in the bug reports - bug 200208 opens with "The general problem is that Mozilla does not differentiate caching and history-list-for-back-button." - I think it's at least a problem for bug reporters that both are called "cache". I don't recall seeing the phrase "session history" refer to anything other than the "history-list-for-back-button", but if that needs a more clearly distinct name, that's fine with me. I'd rather call it the "back sequence" than the frequently misunderstood "cache". Looking at it again, I would add one more bullet to infopage, something like this: • If you want to see the form again, clicking Back again will probably take you to it.