Open Bug 17754 Opened 25 years ago Updated 2 years ago

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

Categories

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

enhancement

Tracking

()

REOPENED
Future

People

(Reporter: CodeMachine, Unassigned)

References

(Blocks 3 open bugs)

Details

(4 keywords, Whiteboard: firefox-doesn't-want (see comment 124))

Attachments

(4 files, 7 obsolete files)

------------------- Subject: Wish: Submit Form to New Window Date: Fri, 29 Oct 1999 13:24:22 -0700 From: Pete Doyle <peted20@earthlink.net> 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?
Assignee: leger → karnaze
QA Contact: leger → cpratt
Chris, an RFE for you? Or would it be for the browser people?
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Marking "later"
Status: RESOLVED → VERIFIED
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 nobody@mozilla.org
Status: VERIFIED → REOPENED
Whiteboard: help wanted
Assignee: karnaze → nobody
Status: REOPENED → NEW
Resolution: LATER → ---
yes, this still hangs for me on winNT.
Cool, a nonexistant feature causes a browser hang. =)
*** Bug 20094 has been marked as a duplicate of this bug. ***
*** Bug 20808 has been marked as a duplicate of this bug. ***
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.
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:)
Adding helpwanted to the keyword field.
Component: Browser-General → Form Submission
Keywords: helpwanted
QA Contact: cpratt → ckritzer
Whiteboard: help wanted
Moving all open "nobody@mozilla.org" assignee bugs to "leger@netscape.com" to review.
Assignee: nobody → leger
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.
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();
Attached patch diffs to patch the M13 package (deleted) — Splinter Review
Moving back to nobody@mozilla.org. This is where the helpwanted will be assigned until someone picks them up.
Assignee: leger → nobody
When this is implimented, shift-click should activate this feature on Win32. cf bug 12056.
... 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.
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
Updating QA contact.
QA Contact: ckritzer → vladimire
See also nsbeta1+ bug 69882, "Middle-click on <input type=image> doesn't work, should open in new window".
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
Summary: Submit form in new window. → Submit button for forms should open in new window.
Summary: Submit button for forms should open in new window. → context item to open form Submit button output in a new window
going to look at this
Blocks: 63823
*** Bug 112086 has been marked as a duplicate of this bug. ***
Depends on: 75338
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.)
Summary: context item to open form Submit button output in a new window → Ability to submit form in a new window
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
*** Bug 125980 has been marked as a duplicate of this bug. ***
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
*** Bug 139738 has been marked as a duplicate of this bug. ***
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
*** Bug 140138 has been marked as a duplicate of this bug. ***
*** Bug 140925 has been marked as a duplicate of this bug. ***
Whiteboard: parity-opera
*** Bug 141360 has been marked as a duplicate of this bug. ***
*** Bug 151813 has been marked as a duplicate of this bug. ***
*** Bug 155168 has been marked as a duplicate of this bug. ***
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.
Blocks: 69882
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.
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.
*** Bug 195337 has been marked as a duplicate of this bug. ***
Summary: Ability to submit form in a new window → Ability to submit form in a new window / tab (when middle-clicked?)
*** Bug 202705 has been marked as a duplicate of this bug. ***
submitting to a new window directly from a select-option is a related desire (http://bugzilla.mozilla.org/show_bug.cgi?id=225212)
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.
*** Bug 229499 has been marked as a duplicate of this bug. ***
*** Bug 243173 has been marked as a duplicate of this bug. ***
*** Bug 245495 has been marked as a duplicate of this bug. ***
Summary: Ability to submit form in a new window / tab (when middle-clicked?) → Ability to submit form in a new window / tab (when button is middle or right clicked)
*** Bug 251340 has been marked as a duplicate of this bug. ***
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.
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.
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.)
Firefox has the same problems. Is it therefore necessary to submit a own bug concerning these problems with Product "Firefox" ???
Assignee: nobody → form-submission
QA Contact: vladimire
*** Bug 262260 has been marked as a duplicate of this bug. ***
submit buttons should act more like standard links. normally opening in current window but middle click/alt click opening in new tab.
*** Bug 268884 has been marked as a duplicate of this bug. ***
*** Bug 270484 has been marked as a duplicate of this bug. ***
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)
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();
FYI: There's a Firefox extension for this. http://dragtotab.mozdev.org/submittotab/
(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?
*** Bug 301126 has been marked as a duplicate of this bug. ***
*** Bug 301299 has been marked as a duplicate of this bug. ***
*** Bug 310212 has been marked as a duplicate of this bug. ***
*** Bug 324040 has been marked as a duplicate of this bug. ***
*** Bug 334281 has been marked as a duplicate of this bug. ***
Whiteboard: parity-opera → parity-opera, parity-safari
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.
> 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.
*** Bug 352088 has been marked as a duplicate of this bug. ***
> 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?
Attached patch Patch 1 (obsolete) (deleted) — Splinter Review
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.
Assignee: form-submission → ventnor.bugzilla
Status: NEW → ASSIGNED
Attachment #273556 - Flags: superreview?(jst)
Attachment #273556 - Flags: review?(jst)
Comment on attachment 273556 [details] [diff] [review] Patch 1 Smaug should look over the event handling changes here...
Attachment #273556 - Flags: review?(jst) → review?(Olli.Pettay)
QA Contact: form-submission
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.
Attached patch Patch 2 (obsolete) (deleted) — Splinter Review
Properly reset the override on every submission.
Attachment #273556 - Attachment is obsolete: true
Attachment #273691 - Flags: superreview?(jst)
Attachment #273691 - Flags: review?(Olli.Pettay)
Attachment #273556 - Flags: superreview?(jst)
Attachment #273556 - Flags: review?(Olli.Pettay)
Attached patch Patch 3 (obsolete) (deleted) — Splinter Review
Suppress autoscroll when we're submitting with middle mouse button.
Attachment #273691 - Attachment is obsolete: true
Attachment #273700 - Flags: superreview?(jst)
Attachment #273700 - Flags: review?(Olli.Pettay)
Attachment #273691 - Flags: superreview?(jst)
Attachment #273691 - Flags: review?(Olli.Pettay)
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.
Attached patch Patch 4 (deleted) — Splinter Review
Fixes review comments. I don't know how a mochitest can test this, but I don't have much experience in developing mochitests anyway.
Attachment #273700 - Attachment is obsolete: true
Attachment #273750 - Flags: superreview?(jst)
Attachment #273750 - Flags: review?(Olli.Pettay)
Attachment #273700 - Flags: superreview?(jst)
Attachment #273700 - Flags: review?(Olli.Pettay)
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.
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-?
(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>
Attached patch Patch 5 (obsolete) (deleted) — Splinter Review
(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.
Attachment #273750 - Attachment is obsolete: true
Attachment #273886 - Flags: superreview?(jst)
Attachment #273886 - Flags: review?(Olli.Pettay)
Attachment #273750 - Flags: superreview?(jst)
Attachment #273750 - Flags: review?(Olli.Pettay)
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.
Attachment #273886 - Attachment is obsolete: true
Attachment #273886 - Flags: superreview?(jst)
Attachment #273886 - Flags: review?(Olli.Pettay)
Attachment #273750 - Attachment is obsolete: false
Attachment #273750 - Flags: superreview?(jst)
Attachment #273750 - Flags: review?(Olli.Pettay)
(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.
Attached patch Middle-mouse paste fixes (deleted) — Splinter Review
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.
(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"?
(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.
(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?
I don't suppose anyone cares about such old regressions these days, but this is a regression from Netscape 4.
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?
Attachment #273750 - Flags: review?(Olli.Pettay)
Comment on attachment 273750 [details] [diff] [review] Patch 4 The patch doesn't apply cleanly anymore and some comments aren't addressed.
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 ?
@ 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 on attachment 273750 [details] [diff] [review] Patch 4 Smaug would be a better reviewer here.
Attachment #273750 - Flags: superreview?(jst)
Attachment #273750 - Flags: superreview?(Olli.Pettay)
Attachment #273750 - Flags: review?(Olli.Pettay)
Comment on attachment 273750 [details] [diff] [review] Patch 4 This needs a new patch
Attachment #273750 - Flags: superreview?(Olli.Pettay)
Attachment #273750 - Flags: review?(Olli.Pettay)
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 -->
Blocks: 565566
Blocks: 565621
But what if th
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.)
Count me in.
How do I set this up?
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
i used odesk.com to advertise some bugs to be fixed for fee (no luck yet)
Whatever happened to the assignee? Did he just give up or something?
Attached patch Proposed patch + test (obsolete) (deleted) — Splinter Review
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.
Assignee: ventnor.bugzilla → sindrebugzilla
Attachment #474429 - Flags: review?(Olli.Pettay)
Has this missed the feature freeze deadline and thus won't make it into Firefox 4 without "special approval"?
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
Attached patch Proposed patch v2 + test (obsolete) (deleted) — Splinter Review
Hides the new context menu items from buttons that don't belong to a form. Fixes a broken part of the test.
Attachment #474429 - Attachment is obsolete: true
Attachment #474508 - Flags: review?(Olli.Pettay)
Attachment #474429 - Flags: review?(Olli.Pettay)
Attached patch Proposed patch v3 + test (obsolete) (deleted) — Splinter Review
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.)
Attachment #474508 - Attachment is obsolete: true
Attachment #474678 - Flags: review?(Olli.Pettay)
Attachment #474508 - Flags: review?(Olli.Pettay)
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.
Attachment #474678 - Flags: review?(Olli.Pettay) → review-
Attached patch Proposed patch v4 + test (deleted) — Splinter Review
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.)
Attachment #474678 - Attachment is obsolete: true
Attachment #474718 - Flags: review?(Olli.Pettay)
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 <sindrebugzilla@gmail.com> >+ * 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; >
Attachment #474718 - Flags: review?(dolske)
Sorry. Not sure what happened there. Didn't mean to post a comment containing the entire diff.
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?
Attachment #474718 - Flags: review?(Olli.Pettay) → review-
I don't think we should take this for Firefox 4; we need to focus on the existing blockers.
Target Milestone: --- → Future
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago14 years ago
Resolution: --- → WONTFIX
Attachment #474718 - Flags: review?(dolske)
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
(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
* 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!)
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.
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. :/
Blocks: cuts-control
@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)
(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.
Mike, why are they loaded? What is the “false, disputed, or question-begging presupposition”?
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?
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.
Whiteboard: parity-opera, parity-safari → [read comment 124 before posting] parity-opera, parity-safari
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).
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [read comment 124 before posting] parity-opera, parity-safari → parity-opera, parity-safari, firefox-doesn't-want
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.
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)
(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?
(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.
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.
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.
*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?
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.
Guys, guys, the bug was reopened. It's not wontfixed anymore. Calm down.
(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...
Assignee: sindrebugzilla → nobody
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
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.
(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 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.)
(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.
Whiteboard: parity-opera, parity-safari, firefox-doesn't-want → parity-opera, parity-safari, parity-chrome, firefox-doesn't-want
(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.
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.
> 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.
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).
There's a new extension, compatible with Firefox 4 https://addons.mozilla.org/addon/tabsubmit/
(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.
I remember Safari creating a background tab when middle-clicking on a Submit button. Nice too.
(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?
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.
Whiteboard: parity-opera, parity-safari, parity-chrome, firefox-doesn't-want → parity-opera, parity-safari, parity-chrome, firefox-doesn't-want (see comment 124)
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.
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.
> 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.
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 staff@mozilla.org explaining your grievances and cross your fingers.
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.
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
Keywords: 4xp
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?
(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.
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.
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.
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).
Yes odd how it works in chromium.
- 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.
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.
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.
(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!
How can that extension function without a chrome.manifest..
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.
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?
If anyone is wondering.. I doubt Pale Moon would disagree with Comment 124.. Also sorry for double post bugspam.
No longer blocks: 565566
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 for more.)
Whiteboard: parity-opera, parity-safari, parity-chrome, firefox-doesn't-want (see comment 124) → firefox-doesn't-want (see comment 124)
Thanks Jonathan. Really appreciate this reminder that Firefox runs on FYGM.
(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.
Component: HTML: Form Submission → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: