Last Comment Bug 451250 - Turn the POSTDATA prompt into an information page (when navigating in session history)
: Turn the POSTDATA prompt into an information page (when navigating in session...
Status: RESOLVED FIXED
parity-ie
: ue
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- normal with 4 votes (vote)
: mozilla10
Assigned To: neil@parkwaycc.co.uk
:
: Andrew Overholt [:overholt]
Mentors:
Depends on: 301471 694397 694793 694963 695325
Blocks: errorpages 324157 506238
  Show dependency treegraph
 
Reported: 2008-08-19 13:35 PDT by Simon Bünzli
Modified: 2012-01-10 12:12 PST (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed patch (17.08 KB, patch)
2011-10-10 15:49 PDT, neil@parkwaycc.co.uk
neil: review+
Details | Diff | Splinter Review
Screen shot (26.22 KB, image/png)
2011-10-11 16:49 PDT, neil@parkwaycc.co.uk
faaborg: ui‑review+
Details

Description Simon Bünzli 2008-08-19 13:35:16 PDT
Whyever this bug hasn't been filed during the past 9 years...
Comment 1 Jesse Ruderman 2008-08-19 23:07:13 PDT
Why should it be an error page rather than a dialog?  For resubmitting a Bugzilla query, there's nothing erroneous about it.
Comment 2 Simon Bünzli 2008-08-20 01:54:05 PDT
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.
Comment 3 Jesse Ruderman 2009-05-17 00:14:17 PDT
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 :)
Comment 4 Shad Sterling 2009-07-09 12:05:32 PDT
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.
Comment 5 Shad Sterling 2010-06-26 11:43:07 PDT
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.
Comment 6 Mikko Rantalainen 2010-11-22 23:48:29 PST
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".
Comment 7 neil@parkwaycc.co.uk 2011-10-10 15:49:39 PDT
Created attachment 566065 [details] [diff] [review]
Proposed patch

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.
Comment 8 Alex Faaborg [:faaborg] (Firefox UX) 2011-10-10 16:37:22 PDT
Can you attach a screenshot of the UI and req
Comment 9 Alex Faaborg [:faaborg] (Firefox UX) 2011-10-10 16:38:19 PDT
sorry (submitted by accident) can you attach a screenshot of the UI and request ui-review on that?
Comment 10 neil@parkwaycc.co.uk 2011-10-11 16:49:03 PDT
Created attachment 566396 [details]
Screen shot

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 11 Alex Faaborg [:faaborg] (Firefox UX) 2011-10-11 16:53:23 PDT
Comment on attachment 566396 [details]
Screen shot

thanks

small nit: perhaps "re-request" instead of "rerequest" otherwise ui-review+
Comment 12 Shad Sterling 2011-10-11 17:20:05 PDT
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.
Comment 13 Alex Faaborg [:faaborg] (Firefox UX) 2011-10-11 17:28:59 PDT
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.
Comment 14 neil@parkwaycc.co.uk 2011-10-12 14:31:09 PDT
Pushed changeset 1354c0187053 to mozilla-central.
Comment 15 Reed Loden [:reed] (use needinfo?) 2011-10-15 16:31:18 PDT
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;/
Comment 16 :Ehsan Akhgari 2011-10-15 21:29:30 PDT
(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?
Comment 17 Benoit 2011-10-17 14:46:22 PDT
(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/
Comment 18 neil@parkwaycc.co.uk 2011-10-18 06:53:58 PDT
(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.
Comment 19 neil@parkwaycc.co.uk 2011-10-18 07:00:58 PDT
Oh, I see now, it got added after the initial version of the patch.
Comment 20 neil@parkwaycc.co.uk 2011-10-18 07:03:38 PDT
No, wait, I was looking at the properties file, which isn't branded...
Comment 21 neil@parkwaycc.co.uk 2011-10-18 07:39:33 PDT
(In reply to Benoit from comment #17)
> there is also a typo in this line:
> 
> s/precuation/precaution/

Bug 694397?
Comment 22 Shad Sterling 2011-11-13 10:31:23 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.