Turn the POSTDATA prompt into an information page (when navigating in session history)

RESOLVED FIXED in mozilla10

Status

()

Core
Document Navigation
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: Simon Bünzli, Assigned: neil@parkwaycc.co.uk)

Tracking

(Blocks: 3 bugs, {ue})

Trunk
mozilla10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: parity-ie)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Whyever this bug hasn't been filed during the past 9 years...
Flags: wanted1.9.1?

Comment 1

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

Comment 2

9 years ago
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.
Summary: turn the POSTDATA prompt into an error page → turn the POSTDATA prompt into an information page (similar to error pages)
Whiteboard: parity-ie

Updated

9 years ago
Depends on: 301471
(Reporter)

Updated

9 years ago
Flags: wanted1.9.1? → wanted1.9.2?

Comment 3

8 years ago
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

8 years ago
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.
Blocks: 506238
(Reporter)

Updated

8 years ago
Flags: wanted1.9.2?

Comment 5

7 years ago
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

7 years ago
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".
(Assignee)

Comment 7

6 years ago
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.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #566065 - Flags: ui-review?(faaborg)
Attachment #566065 - Flags: review+
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?
(Assignee)

Comment 10

6 years ago
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.
Attachment #566396 - Flags: ui-review?(faaborg)
Comment on attachment 566396 [details]
Screen shot

thanks

small nit: perhaps "re-request" instead of "rerequest" otherwise ui-review+
Attachment #566396 - Flags: ui-review?(faaborg) → ui-review+

Comment 12

6 years ago
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.
(Assignee)

Comment 14

6 years ago
Pushed changeset 1354c0187053 to mozilla-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Depends on: 694397

Updated

6 years ago
Target Milestone: --- → mozilla10
Version: unspecified → Trunk
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?
Depends on: 694793
Depends on: 694963

Comment 17

6 years ago
(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/
(Assignee)

Comment 18

6 years ago
(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.
(Assignee)

Comment 19

6 years ago
Oh, I see now, it got added after the initial version of the patch.
(Assignee)

Comment 20

6 years ago
No, wait, I was looking at the properties file, which isn't branded...
(Assignee)

Updated

6 years ago
Depends on: 695325
(Assignee)

Comment 21

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

Bug 694397?

Updated

6 years ago
Summary: turn the POSTDATA prompt into an information page (similar to error pages) → Turn the POSTDATA prompt into an information page (when navigating in session history)

Updated

6 years ago
Attachment #566065 - Flags: ui-review?(faaborg)

Comment 22

6 years ago
(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.
You need to log in before you can comment on or make changes to this bug.