17754 - Ability to submit form in a new window / tab (when button is middle or right clicked)

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Matthew Tuck [:CodeMachine]]

-------------------

Subject:
            Wish: Submit Form to New Window
       Date:
            Fri, 29 Oct 1999 13:24:22 -0700
       From:
            Pete Doyle <[e-mail]>
 Organization:
            Another Netscape Collabra Server User
 Newsgroups:
            netscape.public.mozilla.wishlist

One thing that has kind of annoyed me about browsers is that you can't
submit a form, and have the resulting page come up into a new window.

It would be really nice if I could right click on the submit button, and
say "Submit to new window" (Or whatever it would be called.)

One example situation where I would use this is at www.amazon.com.
Every once in a while I will go there to research a few CDs.  I'd like
to be able to use the search form from the main page and enter the first
search (and have results pop up in a new window) and just go back to the
first window and do the same for the 2nd search.  Its a little thing,
but I think it would be nice.

------------------------

According to my understanding this should be possible with simple forms?

Perhaps a right click on the submit button?

Comment 1

[Paul MacQuiddy]

Chris, an RFE for you? Or would it be for the browser people?

Comment 2

[karnaze (gone)]

Marking "later"

Comment 3

[Phil Peterson]

PMFJI, but rather than resolving this later, it might be better to put it on the
"help wanted" list (see http://www.mozilla.org/get-involved.html). That way,
mozilla contributors can pick it up if they want. Just put [help wanted] in the
status whiteboard and optionally reassign to [e-mail]

Comment 4

[Chris McAfee]

yes, this still hangs for me on winNT.

Comment 5

[Matthew Tuck [:CodeMachine]]

Cool, a nonexistant feature causes a browser hang.  =)

Comment 6

[Matthew Tuck [:CodeMachine]]

*** Bug 20094 has been marked as a duplicate of this bug. ***

Comment 7

[Mats Palmgren (inactive)]

*** Bug 20808 has been marked as a duplicate of this bug. ***

Comment 8

[Matthew T (active 1999-2002)]

Really, the context menu for a form submission button should be exactly the same
as that used for a normal hypertext link. That is, not only should you be able
to open the form submission in a new window, but you should also be able to copy
the location to the clipboard, bookmark it, save it to disk, etc.

So apart from associating form submission buttons with the same context menus as
links, the only extra bit of glue required is to construct the relevant URL for
whatever operations the user chooses to carry out on the submission location.

Comment 9

[Hervé Renault]

i agree with this request !
for big forms like the query page of bugzilla where you have to submit and go
back (to refine your search) a lot of times, it's annoying to have to redraw the
form page each time you go back, because it's heavy and takes some time.
that's a case where having this right click -> "submit in new window" would be
very cool.
www.deja.com is another example...
(i put myself in Cc:)

Comment 10

[leger]

Adding helpwanted to the keyword field.

Comment 11

[leger]

Moving all open "[e-mail]" assignee bugs to "[e-mail]" to 
review.

Comment 12

[Hervé Renault]

i've tried to understand what is needed to implement this feature, and i managed
to make a "dirty hack" that seems to work.
well, this is probably not the right solution but i'd like to tell you what i've
done anyway...

please note that due to bug 10434, we cannot get the form property of the submit
button yet, and thus this hack works only on the first form (forms[0] of the
document)

i'll try to present this in a diff fashion.

in mozilla/xpfe/browser/resources/content/navigator.xul :
---------------------------------------------------------
@@ 91,113 @@
 <popupset>
     <!-- This is the context menu for the content-area of the navigator
 	   window.  It contains each and every possible menu choice.  The
 	   appropriate items are hidden/shown upon display, based on what
 	   the user has clicked-on.
     -->
     <popup id="context"
 	  oncreate="contextMenu = new nsContextMenu( this );"
 	  ondestroy="contextMenu.onDestroy(); contextMenu = null;">
 
 	  <!-- Open ==================================== -->
 	  <menuitem id="context-openlink"
 		    value="&openLinkCmd.label;"
 		    accesskey=""
 		    oncommand="contextMenu.openLink();"/>
+         <menuitem id="context-submitform"
+                   value="&submitFormCmd.label;"
+                   accesskey=""
+                   oncommand="contextMenu.submitForm();"/>
 	  <menuitem id="context-editlink"
 		    value="&editLinkCmd.label;"
 		    accesskey=""
 		    oncommand="contextMenu.editLink();"/>


in mozilla/xpfe/browser/resources/locale/en-US/navigator.dtd :
--------------------------------------------------------------
@@ 294,297 @@
<!-- Context Menu -->                 
<!ENTITY openLinkCmd.label            "Open link in new window">
<!ENTITY openLinkCmd.accesskey        "o">
<!ENTITY submitFormCmd.label          "Submit in new window">


in mozilla/xpfe/browser/resources/content/nsContextMenu.js :
------------------------------------------------------------
@@ 34,43 @@
function nsContextMenu( xulMenu ) {
    this.target     = null;
    this.menu       = null;
    this.onImage    = false;
    this.onLink     = false;
    this.link       = false;
+   this.onSubmitIt = false;
+   this.action     = false;
    this.inFrame    = false;
    this.hasBGImage = false;

@@ 79,89 @@
    initOpenItems : function () {
        // Remove open/edit link if not applicable.
      //this.showItem( "context-openlink", this.onLink );
        this.showItem( "context-openlink", true );
        this.showItem( "context-editlink", this.onLink );
    
+       // remove submit in new window if not applicable.
+       this.showItem( "context-submitform", this.onSubmitIt );

        // Remove open frame if not applicable.
        this.showItem( "context-openframe", this.inFrame );


@@ 213, @@
 	      } else if (this.target.tagName.toUpperCase() == "INPUT") {               
 		if(this.target.getAttribute( "type" ).toUpperCase() == "IMAGE") {
 		  this.onImage = true;
 		  this.imageURL = this.target.src;
 		}
+		//// <test rv submit in new window !!!! 2000-01-26>
+		else if (this.target.getAttribute( "type" ).toUpperCase() == "SUBMIT") {
+		  dump(" *-*-*-*-*-* here we are on an <input type=submit> !\n");
+		  this.onSubmitIt = true;
+ 		
+		  // here we should find the form that contains this <input type=submit>
+		  // with this.target.form but it does not work yet due to bug #10434
+		  // http://bugzilla.mozilla.org/show_bug.cgi?id=10434
+		  // so for now, this hack works only on the first form of the page...
+                 // 		
+		  // anyway, now i prepend a random value to the form target (if any)
+		  // ** i should ensure it's not an already existing window name!
+		  var myRandomTarget = parseInt(1000*Math.random()) + "_" +
this.target.ownerDocument.forms[0].target;
+ 		
+		  dump(" ==== i'm going to set the document target to " + myRandomTarget +
"\n");
+ 		
+		  this.target.ownerDocument.forms[0].target = myRandomTarget;
+ 		
+		  this.action = this.target.ownerDocument.forms[0].action;
+ 		
+		}
+		//// </test rv !!!! 2000-01-26>
 	      } else if (this.target.getAttribute( "background" )) {
 		this.onImage = true;
 		this.imageURL = this.target.getAttribute( "background" );
 	      }

@@ 282, @@
     // Open linked-to URL in a new window.
     openLink : function () {
       // Determine linked-to URL.
 	 openNewWindowWith( this.linkURL() );
     },
+    // Open submitted Form in a new window.
+    submitForm : function () {
+      dump(" ----- let's open a new window with url : " + this.action + "\n");
+      openNewWindowWith( this.action );
+
+      // set the target back to its original value (if any) by removing the
/^\d+_/ prefix
+      var previousTarget = this.target.ownerDocument.forms[0].target;
+      previousTarget = previousTarget.substring(previousTarget.indexOf("_")+1);
+
+      dump(" =*=*=*=*=*= i'm going to restore the form target to : " +
previousTarget + "\n");
+
+      this.target.ownerDocument.forms[0].target = previousTarget;
+    },
     // Edit linked-to URL in a new window.
     editLink : function () {
 	 BrowserEditPage( this.linkURL() );
     },

that's it.
Regards.

Comment 13

[Hervé Renault]

oops, i made an obvious mistake. in nsContextMenu.js, it's not :

+      dump(" ----- let's open a new window with url : " + this.action + "\n");
+      openNewWindowWith( this.action );

but in fact it is :

+      dump(" ----- let's submit the form !\n");
+      this.target.ownerDocument.forms[0].submit();

Comment 14

[Hervé Renault]

Attachment: diffs to patch the M13 package

Comment 15

[leger]

Moving back to [e-mail].  This is where the helpwanted will be 
assigned until someone picks them up.

Comment 16

[Jesse Ruderman]

When this is implimented, shift-click should activate this feature on Win32.  
cf bug 12056.

Comment 17

[Matthew T (active 1999-2002)]

... Actually, Ctrl+click / Cmd+click.

Basically, almost everything that is possible with a link should also be possible 
with a form submission button. For example ...
* I should be able to Ctrl+click/Cmd+click a button to open the form submission
  in a new window, as I would with a link.
* I should be able to Alt+click/Option+click a button to save the form
  submission straight to disk, as I would with a link.
* I should be able to Shift+click a button to select some of the text in the
  button, as I would with a link.
* For buttons involving GET submissions, I should be able to drag the button to
  my bookmarks or wherever, as I would with a link.

This particular bug -- opening a form submission in a new window -- is the first 
step towards doing that.

Comment 18

[Stanton McCandlish]

From a user/tester perspective: HELL YES!  What a lovely, lovely idea.  I'm so 
glad you want to build this in.  This problem (in every browser) has been 
driving me nuts for years.

From a Mac users perspective:  It'll need to work on Click-hold, 
Ctrl-click-hold, or Cmd-click-hold (to bring up Context Menu with such an 
option), or automatically just do it if you Cmd-click-release on the submit 
button (see my other recent bug reports about the Cmd/Ctrl-click stuff, launchin 
in new windows, and bringing up context menus, for a lot more detail on this. IE 
Mac version has exemplary behavior when it comes to this stuff.  It's very easy 
to get a context menu any way you want and to load stuff in new windows w/o 
having to even use a context menu 

Comment 19

[Vladimir Ermakov]

Updating QA contact.

Comment 20

[Jesse Ruderman]

See also nsbeta1+ bug 69882, "Middle-click on <input type=image> doesn't work, 
should open in new window".

Comment 21

[Jeremy M. Dolan]

almost filed a dupe, making summary more search-friendly

69882 seems to be getting more attention then this (4xp), so hopefully that one
is fixed, which should fix this for free

Comment 22

[Doron Rosenberg (IBM)]

going to look at this

Comment 23

[Niklas Mehner]

*** Bug 112086 has been marked as a duplicate of this bug. ***

Comment 24

[Matthew T (active 1999-2002)]

Restoring (nearly) original summary. accel+click should work in addition to a
shortcut menu item. (Incidentally, the former works in MSIE, but not the latter.)

Comment 25

[m_mozilla]

this should follow the prefs for tabbed browsing and use a new tab if
so-configured by user

if a contextual menu is provided, then that menu might offer *both* options

-matt

Comment 26

[Jonas Jørgensen]

*** Bug 125980 has been marked as a duplicate of this bug. ***

Comment 27

[marlon bishop]

in what cases would users need to recall form submissions,
furthermore, how will they identify stored form submissions???? I do
believe a smarter way to accomplish the task described would be to make use of
form manager feature. that way you could see (and manage) your form properly
edit and identify individual entries. Imagine if you bought something and saved
your form submission as a bookmark. Everytime you launched the bookmark it would
buy the item again? That's a dangerous proposition.

i have posted the 2nd draft to the Context Menu Revision 2 document located:

http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-2.html

Comment 28

[R.K.Aa.]

*** Bug 139738 has been marked as a duplicate of this bug. ***

Comment 29

[Ajay Gautam]

This would be a VERY cool feature to have. I am looking for something like this
for *years* now. With this feature, mozilla will come closer to being my perfect
browser :)

Just added my vote to this feature / bug.

Ajay

Comment 30

[John Levon]

*** Bug 140138 has been marked as a duplicate of this bug. ***

Comment 31

[Jesse Ruderman]

*** Bug 140925 has been marked as a duplicate of this bug. ***

Comment 32

[Boris Zbarsky [:bzbarsky]]

*** Bug 141360 has been marked as a duplicate of this bug. ***

Comment 33

[Sebastian Biallas]

*** Bug 151813 has been marked as a duplicate of this bug. ***

Comment 34

[Robert Wall]

*** Bug 155168 has been marked as a duplicate of this bug. ***

Comment 35

[Vaclav Dvorak]

To comment 27 by marlon bishop:

> in what cases would users need to recall form submissions

In all cases where forms are used in place of links. I believe there are many
such cases - at least, I have certainly felt the need for this feature very,
very often. Perhaps webpage authors sometimes use GET-forms to avoid writing
very long URLs (putting the parameters in <input type=hidden> instead). Or
perhaps they find a button-link more "hip" then a text-link. :-) And in all
cases where a server-side image map is used for navigation, but that's actually
a more specific case handled by bug 69882. And in all cases where you want to
search often for the same thing... Perhaps someone wants to monitor the results
of a particular search on Google every day? I'm sure there are plenty more examples.

> furthermore, how will they identify stored form submissions????

For GET-forms, they won't. And they don't need to, I'd argue. After all, a
GET-form results in a URL that you might as well enter manually with the same
effect, so there's no inherent distinction between a GET-form and a link.

POST-forms are a different case, though. Not only would they certainly be more
difficult to implement (the bookmarking part - not the opening in new window,
hopefully), they are also potentially dangerous, as you suggest (e.g. buying
something again without realizing it). Personally, I suggest not handling the
bookmarking of POST-forms here and filing a new bug to discuss (and maybe
implement) that.

> Imagine if you bought something and saved your form submission
> as a bookmark. Everytime you launched the bookmark it would buy
> the item again? That's a dangerous proposition.

I agree, but I believe this only applies to POST-forms. Nobody in their right
mind would use a GET-form for a thing with such effects (and if they do, they
deserve the problems). After all, Mozilla has a warning when Back-ing to a form
submission result that is not cached, and it only applies to POST-forms, too.

> I do believe a smarter way to accomplish the task described
> would be to make use of form manager feature.

(Assuming POST-forms.) It would probably be easier to implement in the form
manager than with bookmarks, but to me, it would seem a wrong place to put this
feature. I think it's essentially a bookmark, although a special one.

Oops, this turns out much longer than I expected. :-) Sorry if it's all obvious,
but perhaps it should be stated anyway, for the record. Thanks for your attention.

Comment 36

[Jonadab the Unsightly One (Nathan Eady)]

Comment 27:  > in what cases would users need to recall form submissions,

Huh?  What on earth does that have to do with wanting to open a submit link
in a new tab (or window) instead of losing the existing page?  If I am making
a purchase someplace, I may want to retain the extant page in a tab until I 
have completed the order to my satisfaction -- possibly until the item is
delivered.  If I am reading slashdot, I may want to submit the poll in a
separate tab, but I may not be finished reading the front page yet.  This
_ought_ to have been basic functionality from the beginning, in Mosaic.

> Imagine if you bought something and saved your form submission as a 
> bookmark. 

That's a completely unrelated issue.  If you discover a bug that causes Moz
to allow a POST action to be bookmarked and repeated without warning the user,
file that as a separate bug.  This bug is about allowing the user to select
_where_ the result of a form submission is displayed in the first place.

Comment 37

[Manko]

I guess this is one of my favorite wish.

Just my 2c: if target of form is already pointed as "_blank", I would have an
ability to submit form in same window: similar to bug 195069 and bug 78037.

See also http://www.mozilla.org/projects/ui/menus/shortcut/ for proposed UI.

Comment 38

[Daniel Wang]

*** Bug 195337 has been marked as a duplicate of this bug. ***

Comment 39

[Sander]

*** Bug 202705 has been marked as a duplicate of this bug. ***

Comment 40

[Ralf Hauser]

submitting to a new window directly from a select-option is a related desire
(http://bugzilla.mozilla.org/show_bug.cgi?id=225212)

Comment 41

[Marcin Kasperski]

Adding my voice to many people dreaming about this feature, one additional note:
would be nice if it worked also with JavaScript-implemented submits. One could
imagine that temporary redefinition of submit function would do (or temporary
setting that because of the special click any submit of whatever reason should
result in new tab).

And additional note: the absolutely most natural way to get this on Unix is to
use middle-click on the button/jscript link/image.

Comment 42

[Jason Barnabe (np)]

*** Bug 229499 has been marked as a duplicate of this bug. ***

Comment 43

[Olivier Cahagne]

*** Bug 243173 has been marked as a duplicate of this bug. ***

Comment 44

[Jo Hermans]

*** Bug 245495 has been marked as a duplicate of this bug. ***

Comment 45

[Martin Creutziger [:MMx]]

*** Bug 251340 has been marked as a duplicate of this bug. ***

Comment 46

[Norbert]

I think should be possible to hold down CTRL/SHIFT while clicking
submit-buttons of forms or while pressing RETURN within a form-element (a edit
field for example) like it is already possible with links.

Comment 47

[Norbert]

additional to  comment #46

Don't forget that forms also can be sumbmitted while pressing RETURN on focused
input elements. It should also be possible to define the target if doing so.

So I suggest the same keys that can be used for opening links.

Comment 48

[Norbert]

I also agree comment #8 that submit buttons should have a conext menu.



(You may also have a look at bug 251693. The request described there ,the
possibility to force links to open in the current tab, should also be adopted
for forms.)

Comment 49

[Norbert]

Firefox has the same problems. Is it therefore necessary to submit a own bug
concerning these problems with Product "Firefox" ???

Comment 50

[Peter van der Woude [:Peter6]]

*** Bug 262260 has been marked as a duplicate of this bug. ***

Comment 51

[Matt]

submit buttons should act more like standard links. normally opening in current
window but middle click/alt click opening in new tab.

Comment 52

[Erik Fabert]

*** Bug 268884 has been marked as a duplicate of this bug. ***

Comment 53

[Jesse Ruderman]

*** Bug 270484 has been marked as a duplicate of this bug. ***

Comment 54

[glenn n. davis]

My laptop doesnt have a middle button. I use right button to either open in new
page or new tab with LINKS.  is there any reason that this should not work for
SUBMITS as well?  This would permit consistancy and allow the user to be unaware
of the difference between links and submits in  a transparant fashion. and might
allow mid button to be used for something else(if i had one which i do not!)  

Would it be a new bug to request that differences in "duplicate bugs" be posted
as comments in the bug they are transfered to?  I think this might allow
different perspectives on the same issue to be considered before someone spends
hours coding a fix.(if this is a duplicate of another bug i apolgize)

Comment 55

[nrlz]

Calling "submit()" doesn't fire the "onsubmit" event. Some webpages modify the
form when the onsubmit event is called. You might need to manually fire the
event before submitting it or directly call the click() method on the target
submit button.

(In reply to comment #13)
> +      this.target.ownerDocument.forms[0].submit();

Comment 56

[nrlz]

FYI: There's a Firefox extension for this.
http://dragtotab.mozdev.org/submittotab/

Comment 57

[Simon Andrews]

(In reply to comment #56)
> FYI: There's a Firefox extension for this.
> http://dragtotab.mozdev.org/submittotab/

Whilst this is good to know about I don't think an extension is what's needed here.  The ability to have a 
request open in a new tab should be universal in a browser should be universal, we either have it or 
not.  If mozilla allows you to open normal links in a new tab then this should also work the same way 
for form submissions to keep things consistent.

Might it be possible to integrate the appropriate code in the extension into the core application so this 
just works?

Comment 58

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 301126 has been marked as a duplicate of this bug. ***

Comment 59

[Dave Townsend [:mossop]]

*** Bug 301299 has been marked as a duplicate of this bug. ***

Comment 60

[Jo Hermans]

*** Bug 310212 has been marked as a duplicate of this bug. ***

Comment 61

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 324040 has been marked as a duplicate of this bug. ***

Comment 62

[Phil Ringnalda (:philor)]

*** Bug 334281 has been marked as a duplicate of this bug. ***

Comment 63

[Jesse Ruderman]

In Safari, you can press Cmd+enter in a Google search box, or Cmd+click on the search button, to open the results in a new tab.

Comment 64

[Jon B]

> Might it be possible to integrate the appropriate code in the extension into the core application so this 
> just works?

That would not be a good idea.  That extension is an ugly workaround.  It says so right on its own page.  Ideally, buttons should be clickable in exactly the same way that links are.

Comment 65

[Phil Ringnalda (:philor)]

*** Bug 352088 has been marked as a duplicate of this bug. ***

Comment 66

[Rami Lehti]

> That would not be a good idea.  That extension is an ugly workaround.  It says
> so right on its own page.  Ideally, buttons should be clickable in exactly the
> same way that links are.

I agree but is there any chance of getting this functionality in the core application this decade?

Comment 67

[Michael Ventnor]

Attachment: Patch 1

The good news is this honours tab browsing preferences and javascript (eg. returning false stops the submission). The bad news is that for now I can only make this work with middle mouse button, so apologies to the Mac users.

Comment 68

[Johnny Stenback (:jst)]

Comment on attachment 273556 [details] [diff] [review]
Patch 1

Smaug should look over the event handling changes here...

Comment 69

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 273556 [details] [diff] [review]
Patch 1

What happens if user middle-clicks, then event handler calls event.preventDefault() and then user left-clicks. If I read the code correctly 
mOverrideWithBlankTarget isn't reseted properly.

Comment 70

[Michael Ventnor]

Attachment: Patch 2

Properly reset the override on every submission.

Comment 71

[Michael Ventnor]

Attachment: Patch 3

Suppress autoscroll when we're submitting with middle mouse button.

Comment 72

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 273700 [details] [diff] [review]
Patch 3

>Index: content/html/content/public/nsIForm.h
>===================================================================
>RCS file: /cvsroot/mozilla/content/html/content/public/nsIForm.h,v
>retrieving revision 1.28
>diff -u -8 -p -r1.28 nsIForm.h
...
>+   * Set whether or not the form should ignore the target and force the form to submit
>+   * in a new window. False by default, and will reset to false after a successful form
>+   * submission.
>+   *
>+   * @param aOverride whether to force the form to submit in a new window
>+   */
>+  NS_IMETHOD SetOverrideWithBlank(const PRBool aOverride) = 0;
>+
>+  /**

You're changing an interface so you should update its IID.
Btw, is the new method really needed? Couldn't OnSubmitClickBegin just take one
parameter.

Mochitest for all this would be great.

Comment 73

[Michael Ventnor]

Attachment: Patch 4

Fixes review comments. I don't know how a mochitest can test this, but I don't have much experience in developing mochitests anyway.

Comment 74

[Olli Pettay [:smaug][[e-mail]]]

Maybe the mochitest could first open a new window for the form.
Then focus the submit control (at least 3 tests, for type="submit", type="image" 
and <button>) and dispatch a synthesized middle click event 
(synthesizeMouse(...)). That should open a new window/tab in which using 
window.opener one could check whether the opener is the right one. So the ok test 
would be close to window.opener.opener.ok(window.opener.location = "someURL", 
"failed to open a new window"). The test should also capture the case when a new 
window isn't opened, so in that case ok() should fail. But playing a bit with window.opener and window.location should work well enough there to catch both 
failing and successful cases.

Comment 75

[Michael Ventnor]

I tried making a Mochitest but synthesizeMouse won't work because it refers to .boxObject, but this is HTML not XUL. I tried dispatching a click event (which is actually what synthesizeMouse does) from within the actual Mochitest but that doesn't work either because the patch checks for explicit user interaction in order to prevent a popup loophole this may otherwise open. I don't think I'd be able to make a Mochitest for this...

Smaug, can you please mark r+ or r-?

Comment 76

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #75)
> I tried making a Mochitest but synthesizeMouse won't work because it refers 
>to .boxObject, but this is HTML not XUL.
Ah, then one way to use the method might be to set .boxObject before calling
synthesizeMouse:
htmlElement.boxObject = htmlElement.ownerDocument.getBoxObjectFor(htmlElement);

Still some questions...
- I assume the patch doesn't honor browser.tabs.opentabfor.middleclick pref?
  I think it should.
- I don't quite understand why the change to popupStatePusher is needed in
  nsHTMLFormElement::SubmitSubmission. 
- Does the patch work properly when middlemouse.contentLoadURL is true and
  general.autoScroll is false? I think those are the defaults in Unix.
  Test both with <input> and <button>

Comment 77

[Michael Ventnor]

Attachment: Patch 5

(In reply to comment #76)
> (In reply to comment #75)
> > I tried making a Mochitest but synthesizeMouse won't work because it refers 
> >to .boxObject, but this is HTML not XUL.
> Ah, then one way to use the method might be to set .boxObject before calling
> synthesizeMouse:
> htmlElement.boxObject = htmlElement.ownerDocument.getBoxObjectFor(htmlElement);

It still won't work, synthesizeMouse makes a click using dispatchEvent, but since the patch checks for explicit user input (to prevent a popup loophole) there isn't really a way to test this.

> Still some questions...
> - I assume the patch doesn't honor browser.tabs.opentabfor.middleclick pref?
>   I think it should.

There isn't really a way in this part of the codebase to honour that, forms get submitted using OnLinkClickSync, which I believe honours browser.link.open_newwindow

> - I don't quite understand why the change to popupStatePusher is needed in
>   nsHTMLFormElement::SubmitSubmission. 

Without it the popup blocker will block the new tab.

> - Does the patch work properly when middlemouse.contentLoadURL is true and
>   general.autoScroll is false? I think those are the defaults in Unix.
>   Test both with <input> and <button>

This patch fixes that.

Comment 78

[Michael Ventnor]

Comment on attachment 273886 [details] [diff] [review]
Patch 5

Actually, I should probably split that off into a new patch so I can get reviews from the right peers. The Gecko freeze is soon, I'd like to get this in before then so I can address the browser/ and suite/ problems.

Comment 79

[Michael Ventnor]

(In reply to comment #76) 
> - Does the patch work properly when middlemouse.contentLoadURL is true and
>   general.autoScroll is false? I think those are the defaults in Unix.

Can this be made into a follow-up bug? The fix for that doesn't touch Gecko but I would like to get the main code in for 1.9.

Comment 80

[Michael Ventnor]

Attachment: Middle-mouse paste fixes

Since the fix for this is in a totally different part of the codebase, I put it in its own patch so that I can assign the correct reviewers after the main code gets checked in.

I guess I can't get the main code in before M7, though I'll try for 1.9 approval after the freeze since it is a rather small change.

Comment 81

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #77)
> 
> It still won't work, synthesizeMouse makes a click using dispatchEvent, but
> since the patch checks for explicit user input (to prevent a popup loophole)
> there isn't really a way to test this.

? As far as I see synthesizeMouse uses nsIDOMWindowUtils::sendMouseEvent, 
which dispatches the events in the same way as what happened if
user used mouse.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/testing/mochitest/tests/SimpleTest/EventUtils.js&rev=1.4&mark=191-213#180


> 
> > Still some questions...
> > - I assume the patch doesn't honor browser.tabs.opentabfor.middleclick pref?
> >   I think it should.
> 
> There isn't really a way in this part of the codebase to honour that, forms get
> submitted using OnLinkClickSync, which I believe honours
> browser.link.open_newwindow

Hmm, then middle click doesn't work consistently. That isn't good for
user experience.

And one new question. How can the UI be mapped to this new functionality, i.e. 
how can one implement the similar context menu what links have currently
"Open Link in New Window"/"Open Link in New Tab"?

Comment 82

[Michael Ventnor]

(In reply to comment #81)
> (In reply to comment #77)
> > 
> > It still won't work, synthesizeMouse makes a click using dispatchEvent, but
> > since the patch checks for explicit user input (to prevent a popup loophole)
> > there isn't really a way to test this.
> 
> ? As far as I see synthesizeMouse uses nsIDOMWindowUtils::sendMouseEvent, 
> which dispatches the events in the same way as what happened if
> user used mouse.
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/testing/mochitest/tests/SimpleTest/EventUtils.js&rev=1.4&mark=191-213#180

er... I was looking at the sendMouseEvent on line 18... I'll look at it again.

> > 
> > > Still some questions...
> > > - I assume the patch doesn't honor browser.tabs.opentabfor.middleclick pref?
> > >   I think it should.
> > 
> > There isn't really a way in this part of the codebase to honour that, forms get
> > submitted using OnLinkClickSync, which I believe honours
> > browser.link.open_newwindow
> 
> Hmm, then middle click doesn't work consistently. That isn't good for
> user experience.

I can't think of any way to deal with it though. Doing so would require quite a large change, if it can be done at all.

> And one new question. How can the UI be mapped to this new functionality, i.e. 
> how can one implement the similar context menu what links have currently
> "Open Link in New Window"/"Open Link in New Tab"?

You can't really. Those context menus are dealt with in browser/ or suite/, not content/. The forms listen for events themselves in content/ so a context menu wouldn't really work.

I'd rather that this change remain simple and reasonably self-contained to prevent bugs and keep it safe for 1.9.

Comment 83

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #82)
> > > > Still some questions...
> > > > - I assume the patch doesn't honor browser.tabs.opentabfor.middleclick pref?
> > > >   I think it should.
> > > 
> > > There isn't really a way in this part of the codebase to honour that, forms get
> > > submitted using OnLinkClickSync, which I believe honours
> > > browser.link.open_newwindow
> > 
> > Hmm, then middle click doesn't work consistently. That isn't good for
> > user experience.
> 

Beltzner, do you have any comments to this?


> 
> > And one new question. How can the UI be mapped to this new functionality, i.e. 
> > how can one implement the similar context menu what links have currently
> > "Open Link in New Window"/"Open Link in New Tab"?
> 
> You can't really. Those context menus are dealt with in browser/ or suite/, not
> content/. The forms listen for events themselves in content/ so a context menu
> wouldn't really work.

Or to this?

Comment 86

[Roger Lynn]

I don't suppose anyone cares about such old regressions these days, but this is a regression from Netscape 4.

Comment 87

[Derek]

Not to spam this bug but i was wondering if anything is going to happen with this bug any time soon? is anyone working on it? or is any work on it now dead? 

This is a long standing bug and a very annoying bug at that because it is not consistent with the rest of the browser, You can middle click on everything else in the browser to open in a new tab accept for this, We still have to bump submittotab and the right click part is now broken, middle click part still works though, and it seems a lot of us wants this fixed, considering the amount of votes this has got so can i get any news on what is going on with this bug?

Comment 89

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 273750 [details] [diff] [review]
Patch 4

The patch doesn't apply cleanly anymore and some comments aren't addressed.

Comment 90

[David Balažic]

SubmitToTab (latest version, 0.3.5) does no work any more on Firefox v3.0.8, it complains about compatibility.
But on another PC I have FF 3.0.8 with SubmitToTab 0.3.5 (I guess I installed it earlier, then updated FF...).

Any idea how to make it work on a fresh FF install ?

Comment 91

[WulfTheSaxon [:Wulf]]

@ David Balažic

Just install the Nightly Tester Tools extension and override the compatibility. (Note that the context menu portion of the extension will no longer work, but middle-clicking will.)

BTW: This is not the place to ask such things. You've just emailed close to a hundred people by posting here...

Comment 92

[Johnny Stenback (:jst)]

Comment on attachment 273750 [details] [diff] [review]
Patch 4

Smaug would be a better reviewer here.

Comment 93

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 273750 [details] [diff] [review]
Patch 4

This needs a new patch

Comment 95

[David Balažic]

Until the patch makes it into a release:

If anyone has trouble (compatibility) with the SubmitToTab extension, here is a way to fix it without changing Firefox settings or installing yet another extension:
 - install SubmitToTab extension
 - close Firefox
 - open the file %APPDATA%\Mozilla\Firefox\Profiles\WHATEVER.default\extensions\{dc0fa13e-3db0-73ec-e852-912722c85409}\install.rdf

and add the maxVersiob tag so the part of the file looks like this:
 <em:targetApplication>
      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
	<em:minVersion>1.0</em:minVersion>
	<em:maxVersion>3.5.*</em:maxVersion> <!-- add this line -->

Comment 96

[Dave]

But what if th

Comment 97

[David]

Since it's obviously not going to happen otherwise, I would like to pay for this bug to be fixed (which I'll define as accepted in trunk and not backed out for one week)
Is there an established way for me to set up a bounty for this? (negotiate price, etc.)

Comment 98

[David Balažic]

Count me in.

Comment 99

[David]

How do I set this up?

Comment 100

[David]

Ok, it's been another couple weeks of silence.  Since I don't know any kind of escrow service set up for this kind of thing I guess it will have to be a matter of honor?  (Does anyone know such a service?)

So how about this: I'll PayPal the money to whoever's name/e-mail is on the commit which implements this feature.  (After it's stayed committed a full week)
Given the relative simplicity as far as I can tell, how about USD$40 for middle-click and control-click only, and USB$60 for that and the context menu.  Price is negotiable

Since I don't subscribe to the dev mailing lists I would need status updates posted either here (Especially if others want to contribute as well) or to my e-mail.

Thanks

Comment 101

[eyal gruss]

i used odesk.com to advertise some bugs to be fixed for fee (no luck yet)

Comment 102

[imradyurrad]

Whatever happened to the assignee? Did he just give up or something?

Comment 103

[Sindre Dammann]

Attachment: Proposed patch + test

Thought I could give this a shot.

I ended up taking a significantly different approach than Ventnor did, I implemented most of it using javascript (much like the way links are currently handled).

The patch currently implements:
* Middle Click (respects browser.tabs.opentabfor.middleclick)
* Accel+Click
* Alt+Shift+Click
* Shift+Click
* Alt+Click (method=GET only, is it necessary to implement this for POST?)
* "Submit to New Tab" context menu item
* "Submit to New Window" context menu item

The test tests ctrl+click, middle click and normal clicking. Open in new window, alt+click, context menu clicking, etc. are not tested because I have yet to figure out how to write a test for this.

Assigning to myself because the current assignee appears to have abandoned this bug three years ago.

Comment 104

[Mardeg]

Has this missed the feature freeze deadline and thus won't make it into Firefox 4 without "special approval"?

Comment 105

[imradyurrad]

It was supposed to be Sept. 10 but it looks like it's being pushed up to the 17th.
https://wiki.mozilla.org/Platform/2010-09-07

Comment 106

[Sindre Dammann]

Attachment: Proposed patch v2 + test

Hides the new context menu items from buttons that don't belong to a form. Fixes a broken part of the test.

Comment 107

[Sindre Dammann]

Attachment: Proposed patch v3 + test

The patch was using & instead of && once.

Any chance of getting a review before the freeze? Perhaps it would be better to request it from someone else? (Previous experience has taught me that I'm quite incompetent at choosing the correct reviewer.)

Comment 108

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 474678 [details] [diff] [review]
Proposed patch v3 + test

> NS_IMETHODIMP
>+nsHTMLFormElement::MozGetSubmission(nsIDOMElement *originatingElement, nsIInputStream **postData NS_OUTPARAM, nsACString & uri NS_OUTPARAM)
Parameters should be in form aParamaterName

>+{
>+  NS_ENSURE_ARG_POINTER(postData);
>+
>+  nsresult rv;
>+
>+  nsCOMPtr<nsIContent> originatingContent = do_QueryInterface(originatingElement);
>+  nsCOMPtr<nsGenericHTMLElement> originatingHTMLElement 
>+                                = do_QueryInterface(originatingElement);
= should be in the previous line.

>+  nsFormSubmission *submission;
Where is submission deleted? Seems like the object is leaked.
Did you run this all with XPCOM_MEM_LEAK_LOG=1 ?


>@@ -61,9 +62,18 @@ interface nsIDOMHTMLFormElement : nsIDOM
>   readonly attribute nsIDOMHTMLCollection elements;
>   readonly attribute long                 length;
> 
>   void                      submit();
>   void                      reset();
> 
>   // This property returns the resolved action URI.
>   readonly attribute DOMString            mozActionUri;
>+  /** Get the form's submission data.
>+    @param [in] originatingElement
>+      The element that initiated the submit request.
>+    @param [out] postData
>+      The post data to be used in the submission,
>+    @retval
>+      The uri to submit to.
>+  */
>+  ACString                  mozGetSubmission(in nsIDOMElement originatingElement, out nsIInputStream postData);
We certainly don't want to expose mozGetSubmision to webcontent.

And IMO, no feature should depend on whether the method is GET or POST or anything else.
Either it should work in all cases or not work at all.

r-

I'm not a browser/ reviewer, so I didn't look at the browser/ changes.

Comment 109

[Sindre Dammann]

Attachment: Proposed patch v4 + test

Alt+Click (save) functionality dropped as it seems like an unimportant feature for forms. (And I'd rather not rewrite saveURL to support post data.)

Comment 110

[Sindre Dammann]

Comment on attachment 474718 [details] [diff] [review]
Proposed patch v4 + test

>diff --git a/browser/base/content/browser-context.inc b/browser/base/content/browser-context.inc
>--- a/browser/base/content/browser-context.inc
>+++ b/browser/base/content/browser-context.inc
>@@ -51,16 +51,24 @@
>       <menuitem id="context-openlinkintab"
>                 label="&openLinkCmdInTab.label;"
>                 accesskey="&openLinkCmdInTab.accesskey;"
>                 oncommand="gContextMenu.openLinkInTab();"/>
>       <menuitem id="context-openlink"
>                 label="&openLinkCmd.label;"
>                 accesskey="&openLinkCmd.accesskey;"
>                 oncommand="gContextMenu.openLink();"/>
>+      <menuitem id="context-submittotab"
>+                label="&submitCmdToTab.label;"
>+                accesskey="&submitCmdToTab.accesskey;"
>+                oncommand="gContextMenu.submitFormToNewTab();"/>
>+      <menuitem id="context-submittowindow"
>+                label="&submitCmdToWindow.label;"
>+                accesskey="&submitCmdToWindow.accesskey;"
>+                oncommand="gContextMenu.submitFormToNewWindow();"/>
>       <menuseparator id="context-sep-open"/>
>       <menuitem id="context-bookmarklink"
>                 label="&bookmarkThisLinkCmd.label;"
>                 accesskey="&bookmarkThisLinkCmd.accesskey;"
>                 oncommand="gContextMenu.bookmarkLink();"/>
>       <menuitem id="context-savelink"
>                 label="&saveLinkCmd.label;"
>                 accesskey="&saveLinkCmd.accesskey;"
>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js
>@@ -5138,18 +5138,22 @@ function asyncOpenWebPanel(event)
>        if (parent instanceof HTMLAnchorElement ||
>            parent instanceof HTMLAreaElement ||
>            parent instanceof HTMLLinkElement) {
>            if (parent.hasAttribute("href"))
>              linkNode = parent;
>        }
>        parent = parent.parentNode;
>      }
>-   }
>-   else {
>+   } else if (target instanceof HTMLButtonElement ||
>+              (target instanceof HTMLInputElement &&
>+              (target.type == "submit" || target.type == "image"))) {
>+     handleButtonClick(event, target);
>+     return true;
>+   } else {
>      linkNode = event.originalTarget;
>      while (linkNode && !(linkNode instanceof HTMLAnchorElement))
>        linkNode = linkNode.parentNode;
>      // <a> cannot be nested.  So if we find an anchor without an
>      // href, there is no useful <a> around the target
>      if (linkNode && !linkNode.hasAttribute("href"))
>        linkNode = null;
>    }
>@@ -5285,16 +5289,72 @@ function handleLinkClick(event, href, li
>       else
>         openNewWindowWith(href, doc, null, false);
>       event.stopPropagation();
>       return true;
>   }
>   return false;
> }
> 
>+function handleButtonClick(event, buttonNode) {
>+  let target = buttonNode ? buttonNode : event.target;
>+  let form = target.form;
>+  if (!form) {
>+    return false;
>+  }
>+  switch (event.button) {
>+    case 0:
>+#ifdef XP_MACOSX
>+      if (event.metaKey) { // Cmd
>+#else
>+      if (event.ctrlKey) {
>+#endif
>+        var postData = {};
>+        var uri = form.mozGetSubmission(buttonNode, postData);
>+        openNewTabWith(uri, target.ownerDocument, postData.value, null, false);
>+        event.stopPropagation();
>+        return true;
>+      }
>+      
>+      if (event.shiftKey && event.altKey) {
>+        var feedService =
>+            Cc["@mozilla.org/browser/feeds/result-service;1"].
>+            getService(Ci.nsIFeedResultService);
>+        feedService.forcePreviewPage = true;
>+        var postData = {};
>+        var uri = form.mozGetSubmission(buttonNode, postData);
>+        loadURI(uri, null, postData.value, false);
>+        return false;
>+      }
>+      
>+      if (event.shiftKey) {
>+        var postData = {};
>+        var uri = form.mozGetSubmission(buttonNode, postData);
>+        openNewWindowWith(uri, target.ownerDocument, postData.value, false);
>+        event.stopPropagation();
>+        return true;
>+      }
>+
>+      break;
>+      
>+    case 1:    // if middle button clicked
>+      var tab = gPrefService.getBoolPref("browser.tabs.opentabfor.middleclick");
>+      var postData = {};
>+      var uri = form.mozGetSubmission(buttonNode, postData);
>+      if (tab) {
>+        openNewTabWith(uri, target.ownerDocument, postData.value, null, false);
>+      } else {
>+        openNewWindowWith(uri, target.ownerDocument, postData.value, false);
>+      }
>+      event.stopPropagation();
>+      return true;
>+  }
>+  return false;
>+}
>+
> function middleMousePaste(event) {
>   var url = getShortcutOrURI(readFromClipboard());
>   try {
>     makeURI(url);
>   } catch (ex) {
>     // Not a valid URI.
>     return;
>   }
>diff --git a/browser/base/content/nsContextMenu.js b/browser/base/content/nsContextMenu.js
>--- a/browser/base/content/nsContextMenu.js
>+++ b/browser/base/content/nsContextMenu.js
>@@ -173,17 +173,19 @@ nsContextMenu.prototype = {
>         onPlainTextLink = true;
>       }
>     }
> 
>     var shouldShow = this.onSaveableLink || isMailtoInternal || onPlainTextLink;
>     this.showItem("context-openlink", shouldShow);
>     this.showItem("context-openlinkintab", shouldShow);
>     this.showItem("context-openlinkincurrent", onPlainTextLink);
>-    this.showItem("context-sep-open", shouldShow);
>+    this.showItem("context-submittotab", this.onButton);
>+    this.showItem("context-submittowindow", this.onButton);
>+    this.showItem("context-sep-open", shouldShow || this.onButton);
>   },
> 
>   initNavigationItems: function CM_initNavigationItems() {
>     var shouldShow = !(this.isContentSelected || this.onLink || this.onImage ||
>                        this.onCanvas || this.onVideo || this.onAudio ||
>                        this.onTextInput);
>     this.showItem("context-back", shouldShow);
>     this.showItem("context-forward", shouldShow);
>@@ -417,18 +419,17 @@ nsContextMenu.prototype = {
>     }
>     this.showItem("context-media-sep-commands",  onMedia);
>   },
> 
>   // Set various context menu attributes based on the state of the world.
>   setTarget: function (aNode, aRangeParent, aRangeOffset) {
>     const xulNS = "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";
>     if (aNode.namespaceURI == xulNS ||
>-        aNode.nodeType == Node.DOCUMENT_NODE ||
>-        this.isTargetAFormControl(aNode)) {
>+        aNode.nodeType == Node.DOCUMENT_NODE) {
>       this.shouldDisplay = false;
>       return;
>     }
> 
>     // Initialize contextual info.
>     this.onImage           = false;
>     this.onLoadedImage     = false;
>     this.onCompletedImage  = false;
>@@ -567,16 +568,21 @@ nsContextMenu.prototype = {
> 
>           // Remember corresponding element.
>           this.link = realLink;
>           this.linkURL = this.getLinkURL();
>           this.linkURI = this.getLinkURI();
>           this.linkProtocol = this.getLinkProtocol();
>           this.onMailtoLink = (this.linkProtocol == "mailto");
>           this.onSaveableLink = this.isLinkSaveable( this.link );
>+        } else if (!this.onButton && elem.form &&
>+                 (elem instanceof HTMLButtonElement ||
>+                 (elem instanceof HTMLInputElement && 
>+                 (elem.type == "submit" || elem.type == "image")))) {
>+          this.onButton = true;
>         }
> 
>         // Background image?  Don't bother if we've already found a
>         // background image further down the hierarchy.  Otherwise,
>         // we look for the computed background-image style.
>         if (!this.hasBGImage &&
>             !this._hasMultipleBGImages) {
>           let bgImgUrl;
>@@ -691,16 +697,32 @@ nsContextMenu.prototype = {
>     openNewTabWith(this.linkURL, this.target.ownerDocument, null, null, false);
>   },
> 
>   // open URL in current tab
>   openLinkInCurrent: function() {
>     openUILinkIn(this.linkURL, "current", null, null, 
>                  this.target.ownerDocument.documentURIObject);
>   },
>+  
>+  // Submit linked-to form to a new tab.
>+  submitFormToNewTab: function() {
>+    var form = this.target.form;
>+    var postData = {};
>+    var uri = form.mozGetSubmission(this.target, postData);
>+    openNewTabWith(uri, this.target.ownerDocument, postData.value, null, false);
>+  },
>+  
>+  // Submit linked-to form to a new window.
>+  submitFormToNewWindow: function() {
>+    var form = this.target.form;
>+    var postData = {};
>+    var uri = form.mozGetSubmission(this.target, postData);
>+    openNewWindowWith(uri, this.target.ownerDocument, postData.value, false);
>+  },
> 
>   // Open frame in a new tab.
>   openFrameInTab: function() {
>     var doc = this.target.ownerDocument;
>     var frameURL = doc.location.href;
>     var referrer = doc.referrer;
> 
>     return openNewTabWith(frameURL, null, null, null, false,
>@@ -1225,28 +1247,16 @@ nsContextMenu.prototype = {
>     return "contextMenu.target     = " + this.target + "\n" +
>            "contextMenu.onImage    = " + this.onImage + "\n" +
>            "contextMenu.onLink     = " + this.onLink + "\n" +
>            "contextMenu.link       = " + this.link + "\n" +
>            "contextMenu.inFrame    = " + this.inFrame + "\n" +
>            "contextMenu.hasBGImage = " + this.hasBGImage + "\n";
>   },
> 
>-  // Returns true if aNode is a from control (except text boxes and images).
>-  // This is used to disable the context menu for form controls.
>-  isTargetAFormControl: function(aNode) {
>-    if (aNode instanceof HTMLInputElement)
>-      return (!aNode.mozIsTextField(false) && aNode.type != "image");
>-
>-    return (aNode instanceof HTMLButtonElement) ||
>-           (aNode instanceof HTMLSelectElement) ||
>-           (aNode instanceof HTMLOptionElement) ||
>-           (aNode instanceof HTMLOptGroupElement);
>-  },
>-
>   isTargetATextBox: function(node) {
>     if (node instanceof HTMLInputElement)
>       return node.mozIsTextField(false);
> 
>     return (node instanceof HTMLTextAreaElement);
>   },
> 
>   isTargetAKeywordField: function(aNode) {
>diff --git a/browser/base/content/test/Makefile.in b/browser/base/content/test/Makefile.in
>--- a/browser/base/content/test/Makefile.in
>+++ b/browser/base/content/test/Makefile.in
>@@ -92,16 +92,17 @@ endif
> 
> # browser_drag.js is disabled, as it needs to be updated for the new behavior from bug 320638.
> 
> _BROWSER_FILES = \
>                  browser_typeAheadFind.js \
>                  browser_NetworkPrioritizer.js \
>                  browser_allTabsPanel.js \
>                  browser_alltabslistener.js \
>+                 browser_bug17754.js \
>                  browser_bug304198.js \
>                  browser_bug321000.js \
>                  title_test.svg \
>                  browser_bug329212.js \
>                  browser_bug356571.js \
>                  browser_bug380960.js \
>                  browser_bug386835.js \
>                  browser_bug405137.js \
>diff --git a/browser/base/content/test/browser_bug17754.js b/browser/base/content/test/browser_bug17754.js
>new file mode 100644
>--- /dev/null
>+++ b/browser/base/content/test/browser_bug17754.js
>@@ -0,0 +1,119 @@
>+/* ***** BEGIN LICENSE BLOCK *****
>+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1
>+ *
>+ * The contents of this file are subject to the Mozilla Public License Version
>+ * 1.1 (the "License"); you may not use this file except in compliance with
>+ * the License. You may obtain a copy of the License at
>+ * http://www.mozilla.org/MPL/
>+ *
>+ * Software distributed under the License is distributed on an "AS IS" basis,
>+ * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
>+ * for the specific language governing rights and limitations under the
>+ * License.
>+ *
>+ * The Original Code is bug 17754 test.
>+ *
>+ * The Initial Developer of the Original Code is
>+ * Sindre Dammann <[e-mail]>
>+ * Portions created by the Initial Developer are Copyright (C) 2010
>+ * the Initial Developer. All Rights Reserved.
>+ *
>+ * Contributor(s):
>+ *
>+ * Alternatively, the contents of this file may be used under the terms of
>+ * either the GNU General Public License Version 2 or later (the "GPL"), or
>+ * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
>+ * in which case the provisions of the GPL or the LGPL are applicable instead
>+ * of those above. If you wish to allow use of your version of this file only
>+ * under the terms of either the GPL or the LGPL, and not to allow others to
>+ * use your version of this file under the terms of the MPL, indicate your
>+ * decision by deleting the provisions above and replace them with the notice
>+ * and other provisions required by the GPL or the LGPL. If you do not delete
>+ * the provisions above, a recipient may use your version of this file under
>+ * the terms of any one of the MPL, the GPL or the LGPL.
>+ *
>+ * ***** END LICENSE BLOCK ***** */
>+
>+function test() {
>+  waitForExplicitFinish();
>+  let tab1 = gBrowser.selectedTab;
>+  gBrowser.selectedBrowser.loadURI("data:text/html;,<!DOCTYPE HTML>\
>+                                    <HTML><HEAD><TITLE>A</TITLE></HEAD>\
>+                                    <BODY><FORM action='http://example.com'>\
>+                                    <BUTTON id='b1'>B</BUTTON></FORM></BODY>\
>+                                    </HTML>");
>+  
>+  gBrowser.selectedBrowser.addEventListener("load", test1, true);
>+  
>+  // Test that opening in new/current tab with <button> opens in correct tab
>+  function test1() {
>+    gBrowser.selectedBrowser.removeEventListener("load", test1, true);
>+    let win = gBrowser.selectedBrowser.contentWindow;
>+    
>+    EventUtils.sendMouseEvent({type:"click",ctrlKey:true}, 'b1', win);
>+    is(gBrowser.tabs.length, 2, "tab count check 1");
>+    is(gBrowser.selectedBrowser.webProgress.isLoadingDocument, false, "tab loading check 1");
>+    EventUtils.sendMouseEvent({type:"click",button:1}, 'b1', win);
>+    is(gBrowser.tabs.length, 3, "tab count check 2");
>+    is(gBrowser.selectedBrowser.webProgress.isLoadingDocument, false, "tab loading check 2");
>+    EventUtils.sendMouseEvent({type:"click"}, 'b1', win);
>+    is(gBrowser.tabs.length, 3, "tab count check 3");
>+    is(gBrowser.selectedBrowser.webProgress.isLoadingDocument, true, "tab loading check 3");
>+    
>+    gBrowser.removeTab(gBrowser.tabs[2]);
>+    gBrowser.removeTab(gBrowser.tabs[1]);
>+    
>+    gBrowser.selectedBrowser.loadURI("data:text/html;,<!DOCTYPE HTML>\
>+                                      <HTML><HEAD><TITLE>B</TITLE></HEAD>\
>+                                      <BODY><FORM action='http://example.com'>\
>+                                      <INPUT id='b1' value='s' type='submit'/>\
>+                                      <INPUT id='b2' value='s' type='image' \
>+                                      formaction='http://example.org'/>\
>+                                      <INPUT type='text' name='v' value='1'/>\
>+                                      </FORM></BODY></HTML>");
>+  
>+    gBrowser.selectedBrowser.addEventListener("load", test2, true);
>+  }
>+  
>+  // Test that opening in new/current tab with <input type=image/submit> opens in correct tab
>+  // Test that formaction works
>+  // Test that values posted by GET are correct
>+  function test2() {
>+    gBrowser.selectedBrowser.removeEventListener("load", test2, true);
>+    let win = gBrowser.selectedBrowser.contentWindow;
>+    
>+    EventUtils.sendMouseEvent({type:"click",ctrlKey:true}, 'b2', win);
>+    is(gBrowser.tabs.length, 2, "tab count check 4");
>+    is(gBrowser.selectedBrowser.webProgress.isLoadingDocument, false, "tab loading check 4");
>+    gBrowser.browsers[1].addEventListener("load", function(){
>+      is(gBrowser.browsers[1].currentURI.spec, "http://example.org/?x=0&y=0&v=1", "url check 1");
>+      finishtest();
>+    }, true);
>+    
>+    EventUtils.sendMouseEvent({type:"click",button:1}, 'b1', win);
>+    is(gBrowser.tabs.length, 3, "tab count check 5");
>+    is(gBrowser.selectedBrowser.webProgress.isLoadingDocument, false, "tab loading check 5");
>+    gBrowser.browsers[2].addEventListener("load", function(){
>+      is(gBrowser.browsers[2].currentURI.spec, "http://example.com/?v=1", "url check 2");
>+      finishtest();
>+    }, true);
>+    
>+    EventUtils.sendMouseEvent({type:"click"}, 'b2', win);
>+    is(gBrowser.tabs.length, 3, "tab count check 6");
>+    is(gBrowser.selectedBrowser.webProgress.isLoadingDocument, true, "tab loading check 6");
>+    gBrowser.browsers[0].addEventListener("load", function(){
>+      is(gBrowser.browsers[0].currentURI.spec, "http://example.org/?x=0&y=0&v=1", "url check 3");
>+      finishtest();
>+    }, true);
>+    
>+    let countfinish = 0;
>+    function finishtest() {
>+      countfinish++;
>+      if (countfinish >= 3 ) {
>+        gBrowser.removeTab(gBrowser.tabs[2]);
>+        gBrowser.removeTab(gBrowser.tabs[1]);
>+        finish();
>+      }
>+    }
>+  }
>+}
>diff --git a/browser/locales/en-US/chrome/browser/browser.dtd b/browser/locales/en-US/chrome/browser/browser.dtd
>--- a/browser/locales/en-US/chrome/browser/browser.dtd
>+++ b/browser/locales/en-US/chrome/browser/browser.dtd
>@@ -312,16 +312,20 @@ can reach it easily. -->
> <!ENTITY searchFocusUnix.commandkey   "j">
> 
> <!ENTITY openLinkCmdInTab.label       "Open Link in New Tab">
> <!ENTITY openLinkCmdInTab.accesskey   "T">
> <!ENTITY openLinkCmd.label            "Open Link in New Window">
> <!ENTITY openLinkCmd.accesskey        "W">
> <!ENTITY openLinkCmdInCurrent.label     "Open Link">
> <!ENTITY openLinkCmdInCurrent.accesskey "O">
>+<!ENTITY submitCmdToTab.label       "Submit to New Tab">
>+<!ENTITY submitCmdToTab.accesskey   "T">
>+<!ENTITY submitCmdToWindow.label       "Submit to New Window">
>+<!ENTITY submitCmdToWindow.accesskey   "W">
> <!ENTITY openFrameCmdInTab.label      "Open Frame in New Tab">
> <!ENTITY openFrameCmdInTab.accesskey  "T">
> <!ENTITY openFrameCmd.label           "Open Frame in New Window">
> <!ENTITY openFrameCmd.accesskey       "W">
> <!ENTITY showOnlyThisFrameCmd.label     "Show Only This Frame">
> <!ENTITY showOnlyThisFrameCmd.accesskey "S">
> <!ENTITY reloadCmd.commandkey         "r">
> <!ENTITY reloadFrameCmd.label         "Reload Frame">
>diff --git a/content/html/content/src/nsHTMLButtonElement.cpp b/content/html/content/src/nsHTMLButtonElement.cpp
>--- a/content/html/content/src/nsHTMLButtonElement.cpp
>+++ b/content/html/content/src/nsHTMLButtonElement.cpp
>@@ -343,20 +343,23 @@ nsHTMLButtonElement::PreHandleEvent(nsEv
>         return NS_OK;
>     }
>   }
> 
>   // Track whether we're in the outermost Dispatch invocation that will
>   // cause activation of the input.  That is, if we're a click event, or a
>   // DOMActivate that was dispatched directly, this will be set, but if we're
>   // a DOMActivate dispatched from click handling, it will not be set.
>+  nsInputEvent* inputEvent = static_cast<nsInputEvent*>(aVisitor.mEvent);
>   PRBool outerActivateEvent =
>-    (NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent) ||
>+    (NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent) && 
>+    !inputEvent->isShift && !inputEvent->isControl &&
>+    !inputEvent->isMeta && !inputEvent->isAlt) ||
>      (aVisitor.mEvent->message == NS_UI_ACTIVATE &&
>-      !mInInternalActivate));
>+      !mInInternalActivate);
> 
>   if (outerActivateEvent) {
>     aVisitor.mItemFlags |= NS_OUTER_ACTIVATE_EVENT;
>     if (mType == NS_FORM_BUTTON_SUBMIT && mForm) {
>       aVisitor.mItemFlags |= NS_IN_SUBMIT_CLICK;
>       // tell the form that we are about to enter a click handler.
>       // that means that if there are scripted submissions, the
>       // latest one will be deferred until after the exit point of the handler.
>diff --git a/content/html/content/src/nsHTMLFormElement.cpp b/content/html/content/src/nsHTMLFormElement.cpp
>--- a/content/html/content/src/nsHTMLFormElement.cpp
>+++ b/content/html/content/src/nsHTMLFormElement.cpp
>@@ -380,16 +380,52 @@ nsHTMLFormElement::GetMozActionUri(nsASt
>   if (aValue.IsEmpty()) {
>     // Avoid resolving action="" to the base uri, bug 297761.
>     return NS_OK;
>   }
>   return GetURIAttr(nsGkAtoms::action, nsnull, aValue);
> }
> 
> NS_IMETHODIMP
>+nsHTMLFormElement::MozGetSubmission(nsIDOMElement *aOriginatingElement, nsIInputStream **aPostData NS_OUTPARAM, nsACString & aUri NS_OUTPARAM)
>+{
>+  if (!nsContentUtils::IsCallerTrustedForCapability("UniversalXPConnect")) {
>+     return NS_ERROR_DOM_SECURITY_ERR;
>+  }
>+
>+  NS_ENSURE_ARG_POINTER(aPostData);
>+
>+  nsresult rv;
>+
>+  nsCOMPtr<nsIContent> originatingContent = 
>+                                    do_QueryInterface(aOriginatingElement);
>+  nsCOMPtr<nsGenericHTMLElement> originatingHTMLElement =
>+                                    do_QueryInterface(aOriginatingElement);
>+  nsAutoPtr<nsFormSubmission> submission;
>+
>+  rv = GetSubmissionFromForm(this, originatingHTMLElement, getter_Transfers(submission));
>+  NS_ENSURE_SUCCESS(rv, rv);
>+
>+  rv = WalkFormElements(submission);
>+  NS_ENSURE_SUCCESS(rv, rv);
>+  
>+  nsCOMPtr<nsIURI> actionUri;
>+  
>+  rv = GetActionURL(getter_AddRefs(actionUri), originatingContent);
>+  NS_ENSURE_SUCCESS(rv, rv);
>+  
>+  rv = submission->GetEncodedSubmission(actionUri, aPostData);
>+  NS_ENSURE_SUCCESS(rv, rv);
>+
>+  //delete submission;
>+
>+  return actionUri->GetAsciiSpec(aUri);
>+}
>+
>+NS_IMETHODIMP
> nsHTMLFormElement::Submit()
> {
>   // Send the submit event
>   nsresult rv = NS_OK;
>   nsRefPtr<nsPresContext> presContext = GetPresContext();
>   if (mPendingSubmission) {
>     // aha, we have a pending submission that was not flushed
>     // (this happens when form.submit() is called twice)
>diff --git a/content/html/content/src/nsHTMLInputElement.cpp b/content/html/content/src/nsHTMLInputElement.cpp
>--- a/content/html/content/src/nsHTMLInputElement.cpp
>+++ b/content/html/content/src/nsHTMLInputElement.cpp
>@@ -1968,19 +1968,27 @@ nsHTMLInputElement::PreHandleEvent(nsEve
>   // This is a compatibility hack.
>   //
> 
>   // Track whether we're in the outermost Dispatch invocation that will
>   // cause activation of the input.  That is, if we're a click event, or a
>   // DOMActivate that was dispatched directly, this will be set, but if we're
>   // a DOMActivate dispatched from click handling, it will not be set.
>   PRBool outerActivateEvent =
>-    (NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent) ||
>-     (aVisitor.mEvent->message == NS_UI_ACTIVATE &&
>-      !GET_BOOLBIT(mBitField, BF_IN_INTERNAL_ACTIVATE)));
>+      (aVisitor.mEvent->message == NS_UI_ACTIVATE &&
>+      !GET_BOOLBIT(mBitField, BF_IN_INTERNAL_ACTIVATE));
>+  if (!outerActivateEvent) {
>+    outerActivateEvent = NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent);
>+    if (outerActivateEvent && 
>+       (mType == NS_FORM_INPUT_SUBMIT || mType == NS_FORM_INPUT_IMAGE)) {
>+      nsInputEvent* inputEvent = static_cast<nsInputEvent*>(aVisitor.mEvent);
>+      outerActivateEvent = (!inputEvent->isShift && !inputEvent->isControl &&
>+                            !inputEvent->isMeta && !inputEvent->isAlt);
>+    }
>+  }
> 
>   if (outerActivateEvent) {
>     aVisitor.mItemFlags |= NS_OUTER_ACTIVATE_EVENT;
>   }
> 
>   PRBool originalCheckedValue = PR_FALSE;
> 
>   if (outerActivateEvent) {
>@@ -2011,17 +2019,17 @@ nsHTMLInputElement::PreHandleEvent(nsEve
>             DoSetChecked(PR_TRUE, PR_TRUE, PR_TRUE);
>             SET_BOOLBIT(mBitField, BF_CHECKED_IS_TOGGLED, PR_TRUE);
>           }
>         }
>         break;
> 
>       case NS_FORM_INPUT_SUBMIT:
>       case NS_FORM_INPUT_IMAGE:
>-        if(mForm) {
>+        if (mForm) {
>           // tell the form that we are about to enter a click handler.
>           // that means that if there are scripted submissions, the
>           // latest one will be deferred until after the exit point of the handler. 
>           mForm->OnSubmitClickBegin(this);
>         }
>         break;
> 
>       default:
>@@ -2265,24 +2273,23 @@ nsHTMLInputElement::PostHandleEvent(nsEv
>                 }
>                 // else fall through and treat Space like click...
>               }
>               case NS_FORM_INPUT_BUTTON:
>               case NS_FORM_INPUT_RESET:
>               case NS_FORM_INPUT_SUBMIT:
>               case NS_FORM_INPUT_IMAGE: // Bug 34418
>               {
>-                nsMouseEvent event(NS_IS_TRUSTED_EVENT(aVisitor.mEvent),
>-                                   NS_MOUSE_CLICK, nsnull, nsMouseEvent::eReal);
>-                event.inputSource = nsIDOMNSMouseEvent::MOZ_SOURCE_KEYBOARD;
>+                nsKeyEvent* keyEvent = static_cast<nsKeyEvent*>(aVisitor.mEvent);
>                 nsEventStatus status = nsEventStatus_eIgnore;
>-
>-                nsEventDispatcher::Dispatch(static_cast<nsIContent*>(this),
>-                                            aVisitor.mPresContext, &event,
>-                                            nsnull, &status);
>+                rv = DispatchClickEvent(aVisitor.mPresContext, keyEvent, this,
>+                                        PR_FALSE, &status);
>+                if (NS_SUCCEEDED(rv)) {
>+                  aVisitor.mEventStatus = nsEventStatus_eConsumeNoDefault;
>+                }
>               } // case
>             } // switch
>           }
>           if (aVisitor.mEvent->message == NS_KEY_PRESS &&
>               mType == NS_FORM_INPUT_RADIO && !keyEvent->isAlt &&
>               !keyEvent->isControl && !keyEvent->isMeta) {
>             PRBool isMovingBack = PR_FALSE;
>             switch (keyEvent->keyCode) {
>diff --git a/dom/interfaces/html/nsIDOMHTMLFormElement.idl b/dom/interfaces/html/nsIDOMHTMLFormElement.idl
>--- a/dom/interfaces/html/nsIDOMHTMLFormElement.idl
>+++ b/dom/interfaces/html/nsIDOMHTMLFormElement.idl
>@@ -33,26 +33,27 @@
>  * decision by deleting the provisions above and replace them with the notice
>  * and other provisions required by the GPL or the LGPL. If you do not delete
>  * the provisions above, a recipient may use your version of this file under
>  * the terms of any one of the MPL, the GPL or the LGPL.
>  *
>  * ***** END LICENSE BLOCK ***** */
> 
> #include "nsIDOMHTMLElement.idl"
>+#include "nsIInputStream.idl"
> 
> /**
>  * The nsIDOMHTMLFormElement interface is the interface to a [X]HTML
>  * form element.
>  *
>  * For more information on this interface please see
>  * http://www.w3.org/TR/DOM-Level-2-HTML/
>  */
> 
>-[scriptable, uuid(48db9517-3a85-4f6d-af5f-106ce6aadd7d)]
>+[scriptable, uuid(de0e3970-bda2-11df-851a-0800200c9a66)]
> interface nsIDOMHTMLFormElement : nsIDOMHTMLElement
> {
>            attribute DOMString            name;
>            attribute DOMString            acceptCharset;
>            attribute DOMString            action;
>            attribute DOMString            enctype;
>            attribute DOMString            method;
>            attribute DOMString            target;
>@@ -61,9 +62,18 @@ interface nsIDOMHTMLFormElement : nsIDOM
>   readonly attribute nsIDOMHTMLCollection elements;
>   readonly attribute long                 length;
> 
>   void                      submit();
>   void                      reset();
> 
>   // This property returns the resolved action URI.
>   readonly attribute DOMString            mozActionUri;
>+  /** Get the form's submission data.
>+    @param [in] originatingElement
>+      The element that initiated the submit request.
>+    @param [out] postData
>+      The post data to be used in the submission,
>+    @retval
>+      The uri to submit to.
>+  */
>+  ACString                  mozGetSubmission(in nsIDOMElement originatingElement, out nsIInputStream postData);
> };
>diff --git a/toolkit/content/widgets/browser.xml b/toolkit/content/widgets/browser.xml
>--- a/toolkit/content/widgets/browser.xml
>+++ b/toolkit/content/widgets/browser.xml
>@@ -968,16 +968,21 @@
>              mmScrollbarPosition = this.mPrefs.getBoolPref("middlemouse.scrollbarPosition");
>            }
>            catch (ex) {
>            }
> 
>            while (node) {
>              if ((node instanceof HTMLAnchorElement || node instanceof HTMLAreaElement) && node.hasAttribute("href"))
>                return true;
>+               
>+             // bug 17754
>+             if (node instanceof HTMLButtonElement || 
>+                (node instanceof HTMLInputElement && (node.type == "submit" || node.type == "image")))
>+              return true;
> 
>              if (mmPaste && (node instanceof HTMLInputElement || node instanceof HTMLTextAreaElement))
>                return true;
> 
>              if (node instanceof XULElement && mmScrollbarPosition
>                  && (node.localName == "scrollbar" || node.localName == "scrollcorner"))
>                return true;
>

Comment 111

[Sindre Dammann]

Sorry. Not sure what happened there. Didn't mean to post a comment containing the entire diff.

Comment 112

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 474718 [details] [diff] [review]
Proposed patch v4 + test



> NS_IMETHODIMP
>+nsHTMLFormElement::MozGetSubmission(nsIDOMElement *aOriginatingElement, nsIInputStream **aPostData NS_OUTPARAM, nsACString & aUri NS_OUTPARAM)
No need for NS_OUTPARAM
And please keep lines max 80 chars long


>+{
>+  if (!nsContentUtils::IsCallerTrustedForCapability("UniversalXPConnect")) {
>+     return NS_ERROR_DOM_SECURITY_ERR;
>+  }
>+
>+  NS_ENSURE_ARG_POINTER(aPostData);
>+
>+  nsresult rv;
Declare rv when you first time use it.

>+
>+  nsCOMPtr<nsIContent> originatingContent = 
>+                                    do_QueryInterface(aOriginatingElement);
>+  nsCOMPtr<nsGenericHTMLElement> originatingHTMLElement =
>+                                    do_QueryInterface(aOriginatingElement);
Strange indentation.
Should be
  nsCOMPtr<nsIContent> originatingContent = 
    do_QueryInterface(aOriginatingElement);
  nsCOMPtr<nsGenericHTMLElement> originatingHTMLElement =
    do_QueryInterface(aOriginatingElement);


>+  //delete submission;
Strange comment.

>   PRBool outerActivateEvent =
>-    (NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent) ||
>-     (aVisitor.mEvent->message == NS_UI_ACTIVATE &&
>-      !GET_BOOLBIT(mBitField, BF_IN_INTERNAL_ACTIVATE)));
>+      (aVisitor.mEvent->message == NS_UI_ACTIVATE &&
>+      !GET_BOOLBIT(mBitField, BF_IN_INTERNAL_ACTIVATE));
>+  if (!outerActivateEvent) {
>+    outerActivateEvent = NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent);
>+    if (outerActivateEvent && 
>+       (mType == NS_FORM_INPUT_SUBMIT || mType == NS_FORM_INPUT_IMAGE)) {
>+      nsInputEvent* inputEvent = static_cast<nsInputEvent*>(aVisitor.mEvent);
>+      outerActivateEvent = (!inputEvent->isShift && !inputEvent->isControl &&
>+                            !inputEvent->isMeta && !inputEvent->isAlt);
>+    }
>+  }
This is rather strange. Why only submit and image have special "outerActivateEvent".
Why not all?
What would happen if you'd check isShift/isControl/isMeta/isAlt for all types?
Do other browsers accept isShift/isControl/isMeta/isAlt in events which activate the
control (like, does the state of checkbox change if you ctrl+click it)?




>@@ -61,9 +62,18 @@ interface nsIDOMHTMLFormElement : nsIDOM
>   readonly attribute nsIDOMHTMLCollection elements;
>   readonly attribute long                 length;
> 
>   void                      submit();
>   void                      reset();
> 
>   // This property returns the resolved action URI.
>   readonly attribute DOMString            mozActionUri;
>+  /** Get the form's submission data.
>+    @param [in] originatingElement
>+      The element that initiated the submit request.
>+    @param [out] postData
>+      The post data to be used in the submission,
>+    @retval
>+      The uri to submit to.
>+  */
>+  ACString                  mozGetSubmission(in nsIDOMElement originatingElement, out nsIInputStream postData);
This should go to some other interface, IMO, which isn't available to web content at all.
Perhaps a new interface?

Comment 113

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think we should take this for Firefox 4; we need to focus on the existing blockers.

Comment 114

[Justin Dolske [:Dolske]]

I don't think we should do this at all, for a few reasons:

* Uncommon, edge-case functionality. Great to hear there's an addon that implements this, that's where it should probably stay.

* Having buttons do different actions on middle-click or modifiers is odd UI.

* Lots of forms are JS driven anyway, so there's no way to make this function consistently.

Comment 115

[imradyurrad]

So close yet so far. Looks like we'll be celebrating its 10th year.

Further discussion at http://groups.google.com/group/mozilla.dev.apps.firefox

Comment 116

[Chris Lawson (gone)]

(In reply to comment #114)
> I don't think we should do this at all, for a few reasons:
> 
> * Uncommon, edge-case functionality.

Not for search engines. Maybe for a Bugzilla bug, sure, but this isn't even remotely an edge case for search, and there are a LOT of search forms on the Web that can't be integrated into the search field in any browser's UI.

As mentioned by Jesse in comment 63 above, this (at least at the time; I'm not clear if he was referring to the search in the UI or the search on the page http://google.com/ ) works (or worked) in Safari.

> Great to hear there's an addon that
> implements this, that's where it should probably stay.

That doesn't help Gecko browsers like Camino, and the add-on is an admitted awful hack.

> * Having buttons do different actions on middle-click or modifiers is odd UI.

No more odd than doing the same with links, especially in the context of search, as mentioned already.

Was there actual discussion involved in WFing this? If so, I'd like to know where it happened and what the discussion was. It seems kind of weird to WF, out of the blue, a longstanding bug with this many dupes, this many votes, and a seemingly viable patch.

cl

Comment 117

[David]

* The add-on is unmaintained, and its very description is "This extension is an ugly workaround for bug #17754."  I think this is precisely the type of behavior that Is best implemented in the main product.  I also think it's only "Uncommon, edge-case" because it's only available in an add-on, not the other way around.

* Whether a UI is odd is context sensitive, and subjective.  In this case it makes buttons and links work a bit more consistently.  Especially with a working context menu.

* Lots of links are JS driven, and middle clicking isn't consistent there already.  In my opinion It's better to have some links and forms work in a tab-friendly manor than none, it's then up to the individual sites.

Please don't keep this as wontfix - especially not with a patch so close to ready.  Does it really not have enough votes, CC, and comments to indicate that we really want it?  (Some of us enough to put up money even!)

Comment 118

[Timwi]

Justin,

> Having buttons do different actions on middle-click or modifiers is odd UI.

No, it isn’t. Links already do that. Users are generally used to it for links. When it doesn’t work for a button, users get the impression that the browser is broken because “middle-click doesn’t work”.

> Lots of forms are JS driven anyway, so there's no way to make this function
consistently.

Buttons are already inconsistent with links. This would make them consistent.

Making JavaScript-driven elements (whether links or buttons) work on middle-click is a separate issue for a separate bug and does not relate to this one.

Please reopen.

Comment 119

[Mike Beltzner [:beltzner, not reading bugmail]]

I support this WONTFIX, for the reasons Justin gave. Links aren't buttons, and buttons shouldn't have right-click handlers or modifiers, I agree.

I apologize for not weighing in earlier, but interactive changes like this should seek uiwanted (keyword) or ui-review (flag) on a mockup illustrating the desired functionality change. I would have been clearer at that time that this wasn't a change we're interested in taking in Firefox. :/

Comment 120

[David]

@Mike: Can you explain Why you think buttons should be less functional than links?

I know Firefox is not a democracy but are the votes (and dupes, etc.) really that meaningless?
I've already given my reasons why I disagree with Justin's reasons.  Sure this feature would slightly increase the testing surface, but I don't think it's any kind of UI clutter.  (At most one context menu, which would be a subset of what already exists for links)

(Also, I don't know who among us has permissions to change keywords or flags, but certainly standard users such as myself don't - those things would have to be done by "higher ups" since the person who filed it is probably long gone - he stopped commenting here last millennium)

Comment 121

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #120)
> @Mike: Can you explain Why you think buttons should be less functional than
> links?
> I know Firefox is not a democracy but are the votes (and dupes, etc.) really
> that meaningless?
These are loaded questions (http://www.fallacyfiles.org/loadques.html) and not welcome here.

Comment 122

[Timwi]

Mike, why are they loaded? What is the “false, disputed, or question-begging presupposition”?

Comment 123

[David]

Sorry about that. I'll try rewording.  The first one anyway:

Why do you think buttons should not have the behavior that this feature request is about, when links already have it?

Comment 124

[Mike Beltzner [:beltzner, not reading bugmail]]

As I said before: buttons aren't links, and users don't expect modifiers and context menus to act on buttons.

Look, guys: I'm sorry that we don't agree on this, but I'm the product manager for Firefox and one of the user experience decision makers. Further, Dolske's a peer for the component, and the bug was marked WONTFIX with rationale. I know you want the feature, and other people do as well. Votes aren't "really meaningless," but nor are they the sole way we decide what does and doesn't go into the product.

The wonderful thing is that this is an open-source project and it should be pretty easy to have an add-on (restartless, even!) created to provide this functionality for those who desire it. In most cases though, it's not required functionality, and I think can end up being pretty confusing to people who hit upon it by accident.

Consider this scenario:
 - I accidentally have my thumb on the control key when I click submit
 - form submitted to a new tab
 - I close that tab, and then see the form again
 - I could either submit again (oops) or close the tab and get an onbeforeunload handler (oops)

Anyway: this remains WONTFIX. The only reason for a REOPEN is if:

 - someone brings *new* information to the bug (note: OMG CHROME DOES IT!!1!!one isn't considered "new", nor is "everyone I know wants it")
 - soemone in a product leadership position changes their mind or decides to reconsider

Thanks for your time and understanding.

Comment 125

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This bug has turned into a cesspool in recent comments, so it is against my better judgement I'm commenting :(  However:

With all due respect to dolske and beltzner, don't take the browser/ part of this patch in Firefox, then, but please don't WONTFIX a platform bug in a module for which you're not an owner or peer, either; that's not how our module system is supposed to work.

Philosophically (rather than technically; I can't speak to that), it seems like it should be possible to add support for the underlying behavior to the platform and then let consumers determine whether they want to expose the behavior to their front-ends for parity with other user-agents. (Presumably having proper platform support would also let people write extensions that are not awful hacks for the front-ends that didn't want to expose it, in line with dolske's first point in comment 114.)

If the DOM owners and peers (http://www.mozilla.org/about/owners.html#document-object-model) don't think it's a valid thing for Gecko to be able to do, fine, but so far we haven't heard from them (other than their showing a willingness to review the Core parts of the patches here).

Comment 126

[Mike Beltzner [:beltzner, not reading bugmail]]

See? That there? New information.

Smokey: makes sense. Not sure I know how to signal "Firefox doesn't want this" any way other than what I just did.

Comment 127

[Boris Zbarsky [:bzbarsky]]

If someone does want to fix this on the Gecko level, then the right thing seems to be to change the code in nsHTMLFormElement::SubmitSubmission to use "_blank" for the target as needed.  A good question is how to get the information about what's needed into that code.  Perhaps it's possible to get that info off originatingElement, which would presumably be non-null in the cases this bug cares about.  Then the issue becomes that of when to change the state of the submit control to and from whatever state will trigger the submission into a new window.

This will still lose on forms that cancel the original submit and do a new submit async, but those are very rare.

Comment 128

[Timwi]

Mike Beltzner: I respect the decision not to put this into Firefox. Nonetheless, I would respectfully like to ask for some information too, which I don’t have and which hasn’t been provided here (if it has been provided elsewhere, I’m happy with a link to it). Namely:

> As I said before: buttons aren't links, and users don't expect modifiers and
> context menus to act on buttons.

How do you know? How many users have you asked and how do you ensure that it is a representative sample? (Note: “It’s always been that way” isn’t considered an answer to this question)

Comment 129

[David Balažic]

(In reply to comment #114)
> I don't think we should do this at all, for a few reasons:
> 
> * Uncommon, edge-case functionality.

How so? Not many bugs have 121 votes. And the duplicate and CC number is pretty long too. By what metric is this uncommon and edge-case?

> * Having buttons do different actions on middle-click or modifiers is odd UI.

Maybe, but almost every clickable item in the Firefox GUI behaves that way:
 - forward/back buttons
 - reload button
 - home button
 - URL bar (when pressing enter in it)
 - URL bar button
 - search bar (enter)
 - search button
 - bookmark items in bookmark menu
 - bookmark item in the bookmarks toolbar
 - links
 - image links (technically same as regular links, but not to the user)
 - probably a load of others I forgot

Will they be "fixed" ?

> * Lots of forms are JS driven anyway, so there's no way to make this function
> consistently.

True for non-form links and button toos. So what? Remove open in new tab functionality, because it does not work in those cases?

Comment 130

[David Balažic]

(In reply to comment #124)
> In most cases though, it's not required
> functionality, and I think can end up being pretty confusing to people who hit
> upon it by accident.

Behavior consistent with the rest of the GUI is confusing?

Well, thanks for your time and understanding.

Comment 131

[Jesse Ruderman]

If the main concern is accidental new-tab submission, we should just turn it off in the most-likely-to-be-accidental cases.  Such as pressing Cmd+Enter while a textbox has focus, which I do all the time in Safari.

Comment 132

[Simon Andrews]

I really fail to see the distinction between links and buttons.  A button is
just another way of requesting another page (albeit with the option to make a
POST request instead of a GET).

From a consistency point of view it seems odd that if I include a button on a
page I get no option to open that in a new tab, but if I wrap a picture of a
button in a regular link I do.  Surely a button is just a special case of an
image link, just one with its own syntax in HTML.

I guess from the previous comments this seems unlikely to be reviewed (this is
not a democracy etc...) but I'd urge those who made the decision to at least
rethink to themselves the rationale behind this decision and see if it's really
consistent.

Comment 133

[Roger Lynn]

*This is a regression from Netscape 4.*

It was one of the more annoying changes when I moved to Mozilla, which I still use.

> Links aren't buttons, and buttons shouldn't have right-click handlers or modifiers

Most users don't know the difference between a link and a button. The fact that some things mysteriously have less functionality when clicked on than others is really irritating.

Not being able to open a page in a new window or tab just because it happened to be the result of a POST rather than a GET is frankly ridiculous. Why should it not be possible to keep the previous page open when submitting a form, especially as one might have spent considerable time typing data into it? If the history is used to attempt to return to the submitting page, often the data entered is wiped or it hasn't been cached in the first place (#160144 and others). Doesn't that make this a dataloss bug?

Comment 134

[BenB]

If this is going to be a wontfix then at least lets have an addon which is updated and maintained!

I agree with the sentiment... I too would like to see fewer extra features being shoved into the core FF to prevent bloat, and give users the choice to install addons to change functionality (weave/sync for example).

However I do believe that in this case, buttons should be able to act like links from a consistency point of view.

Comment 135

[Garth Wallace]

Guys, guys, the bug was reopened. It's not wontfixed anymore. Calm down.

Comment 136

[Simon Andrews]

(In reply to comment #135)
> Guys, guys, the bug was reopened. It's not wontfixed anymore. Calm down.

I suggest you read comments 125 and 126 before getting too excited...

Comment 137

[Chris Lawson (gone)]

Sindre: Just because Firefox doesn't want this doesn't mean it isn't still useful. Please feel free to continue working on it; see especially comment 127 which will probably be helpful.

cl

Comment 138

[David]

I obviously hadn't considered Gecko and Firefox separate when I came up with the terms of the bounty.  Of course my intension was to get it so I didn't need to hack an extension every new PC and new release (And so it could be used by more people than would find the extension even if it were maintained)

However, If the patch makes it into Gecko (Doesn't need to be the version that 4.0 will use) and could be enabled in Firefox with something as simple as a Jetpack, then I would consider the bounty as satisfied as it can be now.  Not ideal of course, but still progress.

Comment 139

[[Baboo]]

(In reply to comment #124)
> As I said before: buttons aren't links, and users don't expect modifiers and
> context menus to act on buttons.

Well, but it occasionally happens in Microsoft Windows.
Example from XP (dunno how's it in Vista and later): When copying/moving several files in the Windows Explorer and the dialog asking whether a file should be overwritten pops up then there are the buttons "Yes", "Yes to all", "No" and "Cancel", but there is also a "No to all" option by holding shift while clicking "No".

Comment 140

[Patrick Dark]

@Comment 139, [Baboo]: Vista changed this behavior. You now get a dialog box with "Move and Replace", "Don't move", "Move, but keep both files", "Skip", and "Cancel" options. Only the last two buttons look like traditional buttons. The "No to all" option via the Shift key has been replaced with a "Do this for the next <integer> conflicts" check box; you click "Don't move" after the check box has been checked.

There are other examples, however:

Modifiers do affect buttons in Adobe Photoshop CS4 and other Adobe applications though; holding Alt turns the "Cancel" button into a "Reset" button.

You also get button specific menus for each application button and the Start button on the Windows Vista Taskbar and can select multiple application buttons to group them by holding the Ctrl key.

Firefox 3.6, Chrome 7 (Dev), and WIE9 (Beta) all allow you to access a button-specific history list when right-clicking the back/forward buttons. (Opera 10.6 and Safari 5 don't allow this. Every browser except Firefox 3.6 (which uses an down arrow button instead) allows you to also hold the mouse button down on the back/forward buttons to access the same menu as well, but then there's a short delay before the menu displays.)

I'm not seeing any HTML/XHTML button-specific menus in anything except WIE9 though and then I only get a Undo/Cut/Copy/Paste/Delete/Select All menu with all options grayed out, so I'm not sure if that's a bug or what. Modifier keys don't seem to have an effect in any browser. Middle-clicking brings up that annoying autoscrolling thing in every browser instead of providing the expected new window/tab behavior. (I keep autoscrolling disabled in Firefox, so middle-clicking results in focus moving to a button instead.)

Facebook buttons behave as expected though because they aren't proper buttons, but |a| element links restyled to look like buttons.

@Comment 124, Mike Beltzner: IMO, this doesn't need to work everywhere. The reason I voted for this bug is because this missing behavior breaks some sites when "browser.link.open_newwindow" is set to open /all/ content in the same tab by default (a non-default pref setting), so this behavior is only needed (for my use case anyway) when that pref is not set to the default. (Or maybe just add a new option to the pref; I think there's 3 or 4 of them already at this point.)

I used to use this pref and a subpref because I wanted full control over windowing/tabbing behavior in the browser, but I ended up returning them to defaults after I kept having to toggle them due to site breakage.

Unfortunately, some sites, like CodingForums.com (which uses vBulletin), are expecting a new, temporary mini-window that interacts with the page calling it. That would be fine if the mini-window were called from an |a| element since I could just middle-click it, but that mini-window can't be forced into a new tab when called from a button, so the pref has to be toggled. IIRC, I also had this problem on WebCT (which is commonly used to administer online classes by universities/colleges). Both sites choose to handle file uploads by invoking a new window; actual file submission occurs in the original window. (Can't recall any other sites off the top of my head; it's been awhile.)

Comment 141

[Sindre Dammann]

(In reply to comment #140)
> Modifier keys don't seem to have an effect in any browser.
Shift+Click submits to a new tab in Opera.

Comment 142

[Patrick Dark]

(In reply to comment #141)
> (In reply to comment #140)
> > Modifier keys don't seem to have an effect in any browser.
> Shift+Click submits to a new tab in Opera.

Okay, I missed that. Apparently, I wasn't thorough enough. Opera also opens a new tab when Ctrl+Shift or Alt+Shift are used, but not Ctrl+Alt+Shift (Ctrl+Alt = autoscrolling). No other combination seems to do anything on windowing/tabbing.

Apparently, "party-safari" should be "parity-safari-osx"/"parity-safari-mac"  or something because the Command+Click/Enter keyboard shortcuts (per comment 63 and using Ctrl as a substitute for Cmd) don't appear to work in Safari 5 for Windows (using google.com's search to test).

Not sure why you added "parity-chrome" since I don't see Alt/Ctrl/Shift/Alt+Ctrl/Alt+Shift/Ctrl+Shift/Alt+Ctrl+Shift/Windows (all+click) do anything in Chrome 7.0.517.8. Right- and middle-clicking don't work either (despite the hint in comment 124).

Nothing in WIE9 Beta 1 and Fx 3.6 despite another look.

Guessing "firefox-doesn't-want" shouldn't be on the whiteboard.

Comment 143

[Sindre Dammann]

the google.com page is weird, as submit to new tab doesn't work with many browsers there (not sure why).

Try http://www.htmlcodetutorial.com/forms/_FORM.html instead. Submit to new tab was added to chromium in http://code.google.com/p/chromium/issue/detail?id=32525. 

On the aforementioned page (using windows 7):
In Chrome 6.0.472.63 (and SRWare Iron 6.0.475) Ctrl+Click opens in new tab in Chrome, Shift+Click opens in new Window and Alt+Click saves the submission.
In Safari 5.0.2 Ctrl+Click opens in new tab.

Comment 144

[Jinx]

> As I said before: buttons aren't links, and users don't expect modifiers and
> context menus to act on buttons.

As a user, all I expect is consistency.

I haven't read this entire page, but there is obviously a good deal of debate on why this decade-old issue should/should-not be resolved.

I, for one, would appreciate the functionality being native. I have used the "SubmitToTab" extension for a few years now, and am still surprised such a "workaround" is needed. Even if you choose not to support using CTRL/ALT as other browsers do, I cannot see why a context-menu item would not be added.

It may be too late for FF4, but I hope one day when I upgrade FF, I'll see SubmitToTab rendered not incompatible, but obsolete.

Comment 145

[Marat Tanalin]

Yeah. It's sad and strange that bug with such big number of votes is still unfixed (especially considering that there already are appropriate implementations in more than one other browser).

Comment 146

[Arne Stenström]

There's a new extension, compatible with Firefox 4

https://addons.mozilla.org/addon/tabsubmit/

Comment 148

[Nicolas Barbulesco]

(In reply to comment #0)

> One thing that has kind of annoyed me about browsers is that you can't
> submit a form, and have the resulting page come up into a new window.

In the good old days, Mac browsers like IE or iCab did that, with Shift or Apple pressed. Consistently with the same behaviour for the address bar. Both these features were nice.

Comment 149

[Nicolas Barbulesco]

I remember Safari creating a background tab when middle-clicking on a Submit button. Nice too.

Comment 150

[Roger Lynn]

(In reply to comment #148)
> In the good old days, Mac browsers like IE or iCab did that,

*Netscape* (ie Mozilla) used to do this with a middle or Ctrl click, but someone decided it would be a good idea to change it!

For some reason it's fine for some things to open in a new window/tab when middle/Ctrl clicked on, but not others. How do you add the regression flag to a bug?

Comment 151

[Matt McCutchen]

Folks, Mike Beltzner has stated his decision on behalf of the Firefox team in comment 124 and is under no obligation to change it because you disagree.  If you care, use the addon or exercise your right to remove the trademarks and fork; the whining and grandstanding is just annoying.

Comment 152

[Timwi]

Have any users of any of the other browsers ever requested for the behaviour to be changed to Firefox’s for any of the reasons Mark mentioned in comment 124?

One reason he’s given is clearly a rare corner-case, and even that corner-case is no worse than the current situation: instead of Ctrl you could accidentally press Esc while the form is submitting, so the same thing is equally (un)likely to happen already. Another reason he gave is an unsubstantiated claim about what “users” expect (i.e. a weasel word), which is in stark contradiction to my experience with users. The rest of his comment is just “I’m the captain, shut up”, which is bossy and unconstructive.

He has also stated in that comment that he wants to hear “new information”, but has merrily ignored all the comments that provide such information. He disregards the information that the current behaviour is inconsistent and this inconsistency regularly trips up non-technical users who don’t care that a button is different from a link for some (mostly historical) technical reason. He disregards the principle of least surprise, which is particularly pertinent in cases where websites deliberately style the links and buttons to be visually indistinguishable (visual consistency, a good UI principle).

Some more new information that hasn’t been mentioned (at least not that I noticed, sorry if I missed it):

• The suggested workaround, to install an add-on, is undiscoverable to almost anyone who isn’t a hardcore user.

• Even to people who know about add-ons, installing it has multiple costs associated with it, including (but not limited to) the possibility of incompatibility with other add-ons; the need to wait for the add-on’s developer to update it every time Firefox goes into a new version; and the increased loading time.

By contrast, the cost of adding this feature is negative because it removes special-casing.

Comment 153

[Matt McCutchen]

Timwi, all of the points you mention are basic enough that I think we can presume Beltzner was aware of them even if they were never stated explicitly.

(In reply to comment #152)
> Another reason he gave is an
> unsubstantiated claim about what “users” expect (i.e. a weasel word), which
> is in stark contradiction to my experience with users.

Well, it's hard to evaluate either his claim or yours.  But that's beside the point, because...

> The rest of his
> comment is just “I’m the captain, shut up”

Which is true.  If you can be a better captain and maintain a better product, be our guest.  It is your continued attempts to compel him to do as you wish that are bossy and unconstructive, in light of the circumstances.

> By contrast, the cost of adding this feature is negative because it removes
> special-casing.

The delta in code size is far from the only consideration.

Comment 154

[Timwi]

> If you can be a better captain and maintain a better product, be our guest

OK, where do I sign up? :-p

> It is your continued attempts to compel him to do as you wish that are bossy
> and unconstructive

Really? I thought my comment was reasoned and constructive. If you think Mark is aware of all these points, why doesn’t he address them and instead just forces a decision that clearly goes against them?

I wasn’t referring just to the code size delta.

Comment 155

[Carlos Alén Silva]

Is Mike Beltzner still the captain of this ship? http://beltzner.ca/mike/2011/04/08/bye-mozilla-com-but-not-mozilla-community/

From my experience, votes do nothing/very little to get a bug even looked at. Posting from a @mozilla.org address does. A lot. Anyway, try sending an e-mail to [e-mail] explaining your grievances and cross your fingers.

Comment 156

[Roger Lynn]

Apparently this regression doesn't need fixing because extensions are available which do the same thing. But the extensions get broken every time there's a new release and at present they haven't worked for months or years. TabSubmit only supports up to Seamonkey 2.1 while 2.4 is about to be released.

Comment 157

[Nicolas Barbulesco]

If this is a regression, this has to be fixed.
I want this feature in the Web browser, without needing to install an extension.
Plug this feature to middle-clicking, Apple-clicking, Shift-clicking, Apple-Shift-clicking on the submit button or link.
Like in Safari on Mac.
Even the good old Internet Explorer 5 on Mac has this feature. A Web browser so old that he has no tabs ! And in the address bar too : when I type there a Web address and press Shift-Enter, *a new window* opens the address.
I want the behaviour to be consistent with Apple- or Shift- or middle-clicking on normal links.
I want to use Wikipedia's search field to load a second article, *while keeping the first article*.
Thanks.
Nicolas

Comment 159

[Christian Walde]

So, what is the exact status of this bug? Set as "to be ignored" by some dude who's long left, and still ignored by Mozilla staff? If i were to write up and describe a use case, would it be considered at all, or a waste of my time?

Comment 160

[Andre Klapper]

(In reply to Christian Walde from comment #159)
> So, what is the exact status of this bug?

The status is described in comment 124 and comment 151, plus I recommend the "No obligations" section on https://bugzilla.mozilla.org/page.cgi?id=etiquette.html for a better understanding of expectations.

Comment 161

[Christian Walde]

I understand the obligation bit, i've released more than enough open source software in my day. Nevertheless this ticket is confusing, because it is currently "REOPENED", but apparently someone had historically decided no and it is completely unclear which of these bits is more relevant. Additionally, the original decision of "no" was followed by "unless you have new information". Typically i'd regard a proper use case as new information; however that person is now gone and from the comments that followed it is not possible to tell whether anyone is actually still paying attention to this who has any ability to decide anything in this, or whether this just the peanut section now.

Please keep in mind that formal etiquette descriptions can only be reliably applied to normal situations and this ticket is anything but normal at this point. So, i was not asking about what the rule book says, but what the reality of this ticket is; so i would know whether i would waste my time or not.

That said, if as you say, comment 124 is still the most relevant, then please close this ticket again, so its metadata matches reality.

Comment 162

[[Baboo]]

Please read carefully, apparently you missed the part in the discussion that comment 124 was just about Firefox but that this here is a core bug. This is why this bug got re-opened.

Comment 163

[Stefan Neufeind]

I just got to know about TabSubmit. The current version works fine on a recent Firefox-version. Great!
It would be nice to please re-consider this for the core, since it's imho really a inconsistency in usage (middle-click works for links but not for submit-buttons).

Comment 164

[Dan Jacobson]

Yes odd how it works in chromium.

Comment 165

[Serge Lebedev]

I wonder if this bug is going to be fixed ever. I'll check it's status in a couple of decades.

Comment 166

[Tony Mechelynck [:tonymec]]

- The Firefox team have expressed (strongly) that they don't want this capability built into their product, which is of course their right.
- Considering the pitiful lack of manpower in the (volunteer) SeaMonkey team, I don't think a patch will be forthcoming from this side any time soon, regardless of how desirable or undesirable the SeaMonkey Council would rate this bug. Let's add a couple SeaMonkey UI developers to the CC just in case though.
- IIUC, the Core developers have expressed their willingness to review patches aimed at building the backend parts into Gecko, but AFAIK nothing more. (How long Gecko is going to still exist is a different matter.)
- Even if neither Firefox nor SeaMonkey exposes this capability, it might be easier to implement even for add-on writers if someone writes a backend patch for it (which would have to come from the "community", i.e. from a volunteer, see above bullet point).
- I'd gladly write a patch for it, and maybe someday I will, but I don't think that I have the required expertise at the moment.

Conclusion: AFAICT, getting this "usefully" fixed would probably require:
- a Core patch from a volunteer for the backend;
- a XUL add-on (hopefully restartless) for the frontend. (Please make it compatible with at least Firefox and SeaMonkey, and possibly PaleMoon, by means of the appropriate <em:targetApplication> sections in install.rdf.)

IMHO it would make sense for both parts to be written by a single coder but of course I cannot require anyone to do it, just hope for it to happen.

Comment 167

[Murz]

I have use this https://addons.mozilla.org/ru/firefox/addon/submittotab/?src=ss extension as workaround for this issue, but build-in feature will be much better!
It works normally on Firefox 43 with ignoring checkCompatibility feature.

Comment 168

[Stefan Neufeind]

Re comment 167: I can confirm that plugin "SubmitToTab" works well for me since quite a while. Very handy. Would be great to have that simple functionality in the core imho.

Comment 169

[Tony Mechelynck [:tonymec]]

(In reply to Stefan Neufeind from comment #168)
> Re comment 167: I can confirm that plugin "SubmitToTab" works well for me
> since quite a while. Very handy. Would be great to have that simple
> functionality in the core imho.

Too bad it does not support SeaMonkey!

Comment 170

[Matt A. Tobin]

How can that extension function without a chrome.manifest..

Comment 171

[frederik]

I agree with comment #133 that this is a data loss bug. My top reason for wanting this feature is to preserve form data that I've taken some time in entering, in case submission fails.

Comment 172

[Matt A. Tobin]

I have a question.. In an e10s world where each content tab is separate from every other tab wouldn't this put an unreasonable amount of cross content process IPC that would have to go through the main process from one tab to another making it exceptionally more complex and could as a result open a door for cross process exploits from one content tab to another?

Comment 173

[Matt A. Tobin]

If anyone is wondering.. I doubt Pale Moon would disagree with Comment 124.. Also sorry for double post bugspam.

Comment 175

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 for more.)

Comment 176

[Christian Walde]

Thanks Jonathan.

Really appreciate this reminder that Firefox runs on FYGM.

Comment 177

[Graham Perrin]

(In reply to Jesse Ruderman from comment #63)

> In Safari, you can press Cmd+enter …

When I began switching away from Mac OS X around four years ago, Safari Command-Return was the feature that was most obviously missing from Firefox. It's taken that long … years … for me to stumble across this bug, via <http://dragtotab.mozdev.org/submittotab/>. FWIW I rank it #2 amongst annoyances. 

Side note (separate issue): Command-Return seems to be defeated by the search field at the new <https://addons.mozilla.org/> … not an issue with classic AMO. 


(In reply to nrlz from comment #56)

> FYI: There's a Firefox extension for this. …

SubmitToTab <https://addons.mozilla.org/addon/submittotab/> seems to no longer work. Tested with the 'Quick search' button at <https://bugzilla.mozilla.org/> with Waterfox 56.2.1.19_2 on FreeBSD-CURRENT. 

Instead, after paging down at <https://addons.mozilla.org/search/?q=TabSubmit&type=extension>: 

- TabSubmit Basic
  <https://addons.mozilla.org/addon/tabsubmit-basic/>
  <https://github.com/mikeconley/tab-submit-basic>

> … a rewrite of the now unmaintained TabSubmit (which is, 
> ironically, a rewrite of the still older SubmitToTab). …

All hail Mike Conley! An end to the annoyance.

Comment 178

[Neeraj]

$('#submit_button').click(function(e) {
$(this).attr("href", "javascript:void(0)"); //reset by every click.
$('#my_form').removeAttr("target"); //reset
if (e.button == 1) //middle mouse button
{
e.preventDefault(); //stop the default behavior of the middle mouse button
$('#my_form').attr("target", "new_window");
}
$('#my_form').submit();

return false;

});
You could try this code for the middle mouse button, for the open in new tab variant you could do this. It's really dirty, so dirty it becomes good!

$('#submit_button').contextmenu(function(e) {
window.onbeforeunload = function() {
//You do want to check here if the unload came from the right source

  localStorage.setItem(name, $('#your_inputs').val());
  //save your form data to local storage

}
$(this).attr("href", location.href);
//set the link to reload itself
$('#my_form').attr("target", "new_window");
//set the target to a new window

});

//put this by default on your page, when it detect local storage submit.
window.onload = function() {

var name = localStorage.getItem(name);
if (name !== null)
{
  //repopulate the form and send to server using normal post
  //delete the local storage items after this.
}

https://www.cronj.com/frontend-development/html.html

Comment 179

[Sylvestre Ledru [:Sylvestre]]

That ship has sailed a long time ago.

Seems that https://addons.mozilla.org/firefox/addon/tabsubmit-basic/ is doing the job!