816148 - Include more data in prompts

Status: NEW

(Toolkit :: General, enhancement)

Description

[JDev]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Upon loading a previous session the information available in a a prompt that requires the user to take action before anything else is clickable is insufficient.  If the site uses long URLs/non-descriptive titles a re-POST data prompt could be a simple search or it could be re-posting a form you don't want re-posted (like adding items to a cart/submitting an order/forum post/etc).  A "view data" button would be helpful to identify what is being submitted.  Access to the full URL/title would also be useful in identifying what these prompts are for (tooltips on tab titles are inaccessible while the prompt is active since it always has focus)

Comment 1

[JDev]

Additionally:  What site posted non-blocking prompts would also be useful.  Example:  confirm() or prompt() sent from a 3rd party script could look like it's coming from a legitimate source for a legitimate reason even if it's an XSS/phishing.

Comment 2

[Wayne Mery (:wsmwk)]

Is this about session restore?

Comment 3

[JDev]

No, this is about prompts.  Some of this has already been corrected, such as prompt() and confirm() which now reside in the scope of the tab not the browser.  There are still some legacy prompts in use such as the "Are You Sure?" prompt.  If one of these prompts is active and the browser crashes or is terminated via the task manager, session restore will restore the prompt as well (as it should).  However, the user may not remember the context for this prompt (ie: the action that caused it) and the prompt itself provides no context itself.

Comment #2 can likely be disregarded now as prompt() was corrected and I cannot think of any other browser scope prompts which can accept user input.

Comment 4

[JDev]

Sorry, that should have said comment #1 could be disregarded.

Comment 5

[:Gijs (he/him)]

(In reply to JMJimmy from comment #0)
> Upon loading a previous session the information available in a a prompt that
> requires the user to take action before anything else is clickable is
> insufficient.  If the site uses long URLs/non-descriptive titles a re-POST
> data prompt could be a simple search or it could be re-posting a form you
> don't want re-posted (like adding items to a cart/submitting an order/forum
> post/etc).  A "view data" button would be helpful to identify what is being
> submitted.  Access to the full URL/title would also be useful in identifying
> what these prompts are for (tooltips on tab titles are inaccessible while
> the prompt is active since it always has focus)

I'm going to be annoying (sorry!) and suggest that while you and I might be technical enough to take advantage of raw form information, the 99% of our users won't be. They're confounded by the "re-send POST" dialog already, and adding raw form data (esp. the gazillion hidden input fields that your average in-the-wild webform uses) doesn't seem like it'll make the dialog more useful.

While we could mark this as wontfix and say "use an add-on"... I'm curious if we can distill the data you're asking for into something more useful for average users.

What exact data are you using to make a decision here? In other words, are you able to describe a loose "algorithm" on how you decide whether or not to re-post stuff?

Orthogonally, we need to ship that dialog as a tab-modal dialog like alert and friends, and that's on our radar (bug 324157), and that will at least fix the "what tab is this about?" question. Would that be enough?

Comment 6

[JDev]

You're right that full POST data is probably too much info for the average user.  Regardless of how technical it is, it should only be represented on the dialog box as a "More info" option.  Personally, I would like to see a minimum of:

 - URL being posted to
 - Content of any non-hidden textarea fields being submitted
 - Content that can be simply identified but is not exhaustive in its application (examples: an email address in an input field, a post variable name which is obvious like one containing "phone").  Meaning its not guaranteed to display if its submitting a field containing your phone number, but if it's simple to identify that's what it is, it will display.  Anything under this section should only be attempting to identify personal/sensitive info being submitted so the user can make an informed decision.

My ideal would be that after clicking "more info", it displays a basic form which includes all non-hidden elements being submitted with an advanced tab containing the full post data.  I'd equate it to the "View Image" vs "View Image Info" options in the image context menu - simple is there, but so is advanced should the user be technical enough.

Comment 7

[JDev]

Re-reading I don't think I answered your questions properly.  


(In reply to :Gijs Kruitbosch from comment #5)
> While we could mark this as wontfix and say "use an add-on"... I'm curious
> if we can distill the data you're asking for into something more useful for
> average users.

There are a couple concerns I see: 
 - Intent to submit data may change between the original posting and the session restore time
 - Data may have been properly submitted but not registered before a crash/unexpected shutdown resulting in duplicate submissions (since the user is blindly selecting "yes" or "no" if they don't remember what was being submitted)
 - Privacy concerns for public or even temporarily shared computers.  If a session is restored by another user, such post data may allow an unintended user to gain access to something they shouldn't.  My ideas don't deal with this directly, I'm not sure it's even possible.  At the very least allow users to make informed decisions before handing over a computer in a temporary share situation.

> Orthogonally, we need to ship that dialog as a tab-modal dialog like alert
> and friends, and that's on our radar (bug 324157), and that will at least
> fix the "what tab is this about?" question. Would that be enough?

That would be enough to address comment #3 for sure, but not the issues related to informed decision making.  The way I think of this issue is, how would someone with short term memory loss deal with such a prompt?  Could they make a reasonably informed decision with the data being presented in the prompt and no memory of what came before?