On the Linux version of Netscape and Mozilla one can normally open a link in a new window by clicking the link with the center button of the mouse. For some types of links which are actually <input> buttons, this doesn't work on Mozilla. The simplest example of this problem that I could find was the personals section on Yahoo! Each personals ad has a link you click to see the complete add. With Netscape 4.x on Linux, you can click this link with the center button and the page opens in a new browser window. But clicking the link with the center button using Mozilla doesn't work. As you mouse over the button, the Mozilla cursor changes from an arrow to a finger which seems to indicate that it's aware of it being a link. On the other hand, right-clicking to bring up the context menu doesn't offer an "open link in new window" option. The URL I included above from Yahoo! looks like it may be dynamic - if it doesn't work, just go to http://personals.yahoo.com/ and then click the "Find my Match!" button. When you get a page of matches, look for the "More" link at the end of each ad and try to open it in a new page by either clicking the center button or right-clicking and using the menu. I'll see if I can track down an even simpler page that demonstrates the problem...

The links in question are actually <input type="image"> elements. Interestingly. NS4.x _does_ open the page resulting from the form post on a middleclick... Over to XP miscellany. It would be nice if this were to work as in NS 4.x

This got put in the wrong component. ben, it probably belongs to you or one of your minions.

blake?

yow, when i middle-click the More button in a given ad here, my default home page loads in the current browser window. [nor does a new browser window open, for that matter.] ->bill? also cc'ing jag.

Marking nsbeta1+, p3, mozilla0.9, reassigning to mcafee to have a look

could this get fixed by moz0.9.1...?

Taking, if Chris doesn't mind, since I did the other modified click stuff... I presume this isn't Linux-only?

See also bug 17754, "Submit form in new window" (6 votes, no owner, future). Does one of these bugs block the other?

jag, maybe you could just fix this in <browser/> so we don't have to mess with contentAreaClick.js.

usability/polish 0.9.4.

This seems to have worked until recently. Was it broken again? BUILD 2001101808 URL http://schedule.berkeley.edu/srchsprg.html Middle clicking 'begin search' will open home page in current window, or try to open one field of the form as the url destination.

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

Is this bug still on the radar (hopefully for 1.0)? I just checked it in 0.9.9 and noticed that a middle-click still brings up the default home page in a new window instead of the intended page. However, a right click no longer even shows the "open in window" option like it used to. So it seems this bug has gotten worse rather than better over time. I didn't realize when I originally reported it that this was a bug that would require more than a year to solve!

jkeiser, this is the bug I was talking to you about a few weeks back when we couldn't figure out a way to post a form to a specified frame short of toggling the form's "target" attribute and then handling the fallout....

Fallout? I can't remember what the fallout is, but it seems like we could make a method on nsIForm that the image click could call to submit the form with another target. This should not be too hard. Blake, are there any difficult issues with middle-mouse-click or is it just a matter of handling it in the frame and passing the event?

The fallout was that twiddling the target attr involves setting it back to the original value once submission is done or something like that. And that starts to suck a lot if DOM accesses the form while submission is happening, for example. The problem with simply handing this in the frame is that then embedding apps get this behavior as well, no? Does the fact that it's following the middle- click pref let us get away with it as far as embedding is concerned? The problem with handling the click in JS (contentAreaClick or in the <browser>/<tabbrowser> bindings) and using a method on nsIForm for the submission is, of course, that nsIForm is not scriptable.

How is submitting a form with an image button different from submitting it with a submit button? In other words, why isn't this a dupe of the (more general) bug 17754, already mentioned in comment 8?

A submit button looks like a submit button and has the submit button cursor. An image input looks like a linked image and has the link cursor. In other words, it is not at all obvious that an image input will submit a form. This certainly depends on the back end work needed in bug 17754.

Bug 17754 is a request for a new feature to allow forms to be submitted in new windows. This bug is an actual bug that needs to be fixed and has nothing to do with submitting forms. Previous versions of Netscape (and some early version of Mozilla I believe) allowed links of all types to be opened in new windows. Recent Mozilla versions, however, broke this ability. Some links can still be opened in new windows but links initiated by javascript actions associated with page elements (in this case a button on a form) cannot be opened in new windows anymore.

Amazon's "add to wishlist"/etc links cause this. Perhaps this should be escalated?

Filter "spam" on "guifeatures-nobody-20080610".

Wow, funny to suddenly get an email on this bug. Maybe it should just be marked as wontfix given that it's been 15 years with no progress since I filed it. lol :)

I have to assume Patrick just got the wrong bug number here, since the bugs he marked as duplicate and depending on this bug have absolutely nothing to do with it....

yep - missing an '8'. thanks.