913907 - Add an option to bypass POSTDATA and onbeforeunload confirmation dialogs by default.

Status: RESOLVED INVALID

(Firefox :: Settings UI, enhancement)

Description

[Darren Johnston]

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130907215322

Steps to reproduce:

Automated browsing sending, collecting, receiving information without user interaction.


Actual results:

On certain pages I get a prompt triggerd by onunload, also other dialogues about loosing postdata.


Expected results:

Many people run their browsers in auto mode to send or receive information and process it through add-on's.  Having any sort of popup dialogue that requires a user response breaks these add-on's.   Please allow an option to auto respond or remove user queries

Comment 1

[Manish Goregaokar [:manishearth]]

Could you give more details on the steps to reproduce? I don't find such a preference at first glance.

Comment 2

[Andre Klapper]

This is way too high level. Please provide specific, reproducible steps/examples.

Comment 3

[Darren Johnston]

The examples are difficult since the pages don't always produce these requests.  However every prompt firefox makes which it expects a user-input either requires script/addon input or automated user-input.  What no one wants is it to hang there waiting for a response until a user shows up 12 hours later.  There are also several complaints about these prompts going back years.

Comment 4

[Darren Johnston]

request dating back to 2007 asking how to get rid of postdata confirm box.  Bad advice was provided as I've tried it.
http://forums.mozillazine.org/viewtopic.php?f=3&t=41934&start=45

request dating back to 2011 asking how to get rid of leaving page confirm box
http://forums.mozillazine.org/viewtopic.php?f=7&t=2178527

We need a method to disable these confirm boxes so they don't interrupt the page or scripts in progress.

Comment 5

[Loic]

Please, don't add a batch of keywords.

Comment 6

[Darren Johnston]

thirdpart -Keyword used for flagging any third party issues and identifying the issues for a particular release.
this complaint is related to third party addons

uiwanted - For bugs that require UI design support, either for a requested feature enhancement, some new function which needs some UI, or a fix to existing UI.

The current behavior is very much unwanted (for years)

ux-control - User experience principle: users should always feel like they are in control of their software. (This principle is often the nemesis of ux-interruption, especially in cases where developers assume users want more control than they actually want). 	

The users of my addon do not feel in control due to the interuptions.

ux-interruption - User experience principle: interfaces should not interrupt the user. Interfaces should never ask the user a question that they are not prepared to answer simply for a false sense of ux-control. In general software should only speak when spoken to.

They are not prepared to answer the question because they are in fact not there.  They would like the addon to continue about it's business.

ux-trust - Use keyword to tag bugs that have an impact on user trust of our products, but aren't necessarily or strictly issues due to performance. For example, if I have to tap a text field 5 times to get it to register and bring up the keyboard, as a user, I will come to expect that and not trust that I can select the text field consistently. This could be due to a small touch target, and is not a performance issue.

The trust has been broken for some time because the browser constantly queries the user who isn't there.  They get to fix it when they show up.  And often it has a negative impact on what they were doing.  Any downtime does.

Loic Why do you have an issue with these?  Why can we not get this fast tracked to get it fixed?  It's been years of complaints related to this on multiple forums.  Google is your friend.

Comment 7

[Manish Goregaokar [:manishearth]]

(In reply to Darren Johnston from comment #6)
> 
> uiwanted - For bugs that require UI design support, either for a requested
> feature enhancement, some new function which needs some UI, or a fix to
> existing UI.

This isn't asking for UI

> ux-control - User experience principle: users should always feel like they
> are in control of their software. (This principle is often the nemesis of
> ux-interruption, especially in cases where developers assume users want more
> control than they actually want). 	
> 
> The users of my addon do not feel in control due to the interruptions.

This means: The user should not have the software do fishy stuff without their consent. Read the statement in parentheses.


> ux-interruption - User experience principle: interfaces should not interrupt
> the user. Interfaces should never ask the user a question that they are not
> prepared to answer simply for a false sense of ux-control. In general
> software should only speak when spoken to.
>
>
> They are not prepared to answer the question because they are in fact not
> there.  They would like the addon to continue about it's business.

"Not prepared to answer" = "Don't know how to answer", or "Don't have enough info to answer".


> ux-trust - Use keyword to tag bugs that have an impact on user trust of our
> products, but aren't necessarily or strictly issues due to performance. For
> example, if I have to tap a text field 5 times to get it to register and
> bring up the keyboard, as a user, I will come to expect that and not trust
> that I can select the text field consistently. This could be due to a small
> touch target, and is not a performance issue.
> 
> The trust has been broken for some time because the browser constantly
> queries the user who isn't there.  They get to fix it when they show up. 
> And often it has a negative impact on what they were doing.  Any downtime
> does.

"Who isn't there" -- that's for your addon. With such a broad meaning then all bugs would get tagged with this.
 
> Loic Why do you have an issue with these?  Why can we not get this fast
> tracked to get it fixed?  It's been years of complaints related to this on
> multiple forums.  Google is your friend.

I can't find anything. I agree that this is a useful thing to have. I disagree that it should be given priority.

Also, to implement this one would have to set up a "default" choice for every interruption that should be chosen when the user has this mode on. Not easy.

Comment 8

[Darren Johnston]

I would like it to do a 'default' and not interrupt the session in progress.  yes.

The two biggest ones are "This page is asking you to confirm that you want to leave - data you have entered may not be saved.:

And 
"The page you are trying to view contains POSTDATA. If you resend the
data, any action the form carried out (such as as search or online
purchse) will be repeated. To resend the data, click OK. Otherwise,
click Cancel."


I've googled at least one complaint dating back to 2002 about this.  It's been over 10 years now.  I know 100,000 of my users would love for these popups which cause stalls to go away.

Comment 9

[Manish Goregaokar [:manishearth]]

> The two biggest ones are "This page is asking you to confirm that you want
> to leave - data you have entered may not be saved.:
> 
> And 
> "The page you are trying to view contains POSTDATA. If you resend the
> data, any action the form carried out (such as as search or online
> purchse) will be repeated. To resend the data, click OK. Otherwise,
> click Cancel."

Um, I think that addons can achieve this by just setting window.onbeforeunload to an empty function.

> I've googled at least one complaint dating back to 2002 about this.  It's
> been over 10 years now.  I know 100,000 of my users would love for these
> popups which cause stalls to go away.

We have no clue what to google for here. Could you give some links to searches?

Comment 10

[Darren Johnston]

Um, I think that addons can achieve this by just setting window.onbeforeunload to an empty function.

When dealing with facebook and security, it's hard to target the right spot.  There are so many layers.  Also when I do get it right, facebook adds yet another frame.  Or changes the names.

https://bugzilla.mozilla.org/show_bug.cgi?id=160144
http://forums.mozillazine.org/viewtopic.php?t=41934
http://www.dynamicdrive.com/forums/showthread.php?36020-PHP-Login-quot-This-page-contains-POST-DATA-quot
http://www.smarty.net/forums/viewtopic.php?p=9613
http://forums.mozillazine.org/viewtopic.php?f=7&t=2178527
https://support.mozilla.org/en-US/questions/954808
https://support.mozilla.org/en-US/questions/951612
https://groups.google.com/forum/#!topic/mozilla.support.firefox/7vsGvolXZC8

It is my view that this should be able to be an about:config setting.

Comment 11

[Manish Goregaokar [:manishearth]]

(In reply to Darren Johnston from comment #10)
 
> When dealing with facebook and security, it's hard to target the right spot.
> There are so many layers.  Also when I do get it right, facebook adds yet
> another frame.  Or changes the names.

Hard, but possible. My point was that there isn't as much urgency when it can be done via addon. 


I see your links, though, and it seems feasible/desirable to add two options: one for the postdata, one for onbeforeunload, where a value of 0 is the default behaviour, and setting 1 or 2 can tell the system to automatically choose one of the two options (1=stay, 2=go).

If we allow the user to select "stay" as a default option, we do have a slight issue if the user really does want to leave, and gets stuck. In that case, there are two further solutions:

 - Bringing up the popup the second time it tries to come
 - Sliding up a non-blocking banner "Your preferences blocked you from navigating away. Would you like to leave anyway?"

I like the latter one.

Not sure if Ill be able to do it myself, but I'll take a look at the code when I'm free.

Comment 12

[Darren Johnston]

Manish I like your solution.  I would prefer the banner as well.

Comment 13

[Manish Goregaokar [:manishearth]]

Anyway, these seems to be enough info in the comments now to make this a  thorough feature request.

Comment 14

[Jesse Ruderman]

I don't think it would make sense to have a single option controlling both onbeforeunload dialogs and postdata.  A pair of prefs (which an add-on for auto browsing could set) might make sense.

For onbeforeunload, there's bug 950336 and bug 578828.

For postdata, bug 290809 might cover your request.  Note that there are several ways to trigger the dialog, and several things that "bypass the dialog" could mean (cancel, resubmit, or the idea in bug 322984).  An API hook might be safer than a pref.

Comment 15

[Florian Bender]

Per comment 14 (see the bugs there), resolving as invalid.

Comment 16

[Darren Johnston]

That is all that is ever done with this bug is to pass the buck.  Since 2001 it has been an issue.

Comment 17

[Darren Johnston]

If you do not leave this one as unresolved, more people will just create more bug reports related to the same bug.

Comment 18

[Manish Goregaokar [:manishearth]]

(In reply to Darren Johnston from comment #16)
> That is all that is ever done with this bug is to pass the buck.  Since 2001
> it has been an issue.

I don't see any passing the buck here. It's consolidating to the main "bug". 

(In reply to Darren Johnston from comment #17)
> If you do not leave this one as unresolved, more people will just create
> more bug reports related to the same bug.

That doesn't seem to follow. Leaving this around doesn't _help_ the issue, since there now is one more parallel discussion about it. The bug has already been filed (well, two bugs), and there is plenty of discussion there. I plan to submit a patch on this when I get time.