350390 - double opening tabs with target='_blank' follow by button

Status: RESOLVED DUPLICATE of bug 346401

(Core :: DOM: Events, defect)

Description

[Didier]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

The following code : <a href='http://www.mozilla-europe.org' target='blank'><input type='button' value='Mozilla'></a> create a button witch open two tabs on a click

Reproducible: Always



Expected Results:  
opening one tab

Comment 1

[Marek Stępień [:marcoos, inactive]]

WFM, Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.1b2) Gecko/2006082101 Firefox/2.0b2

Comment 2

[Marek Stępień [:marcoos, inactive]]

Attachment: Testcase

Ouch, actually it does, but only if target="_blank", and not with target="blank" like in comment 0.

Comment 3

[Marek Stępień [:marcoos, inactive]]

Confirming.

Comment 4

[Didier]

(In reply to comment #3)
> Confirming.
> 
The underscore misses in my comment but not in the summary. I tried with it, then without and the result is the same. 

Comment 5

[Steve England [:stevee]]

I see this too, with
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/20060827 BonEcho/2.0b2
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
New profile in both cases.

Comment 6

[Ria Klaassen (not reading all bugmail)]

Regression between 1.8b2_2005042806 and 1.8b2_2005042906:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-04-28+05%3A00&maxdate=2005-04-29+07%3A00

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Likely a regression from bug 289940.

Comment 8

[WADA:World Anti-bad-Duping Agency]

This bug was observed with <input type=submit/reset> too, in addition to <input type=button>. (When Win32 build, started to occur with trunk 2005/04/29-07 build)
In addition to <input type=submit/button/reset>, same problem(double scheduling of <A HREF>) started to occur on <BUTTON type=submit/button/reset> with Fx 3 (Bug 384364).
Bug 384364 is DUP of this bug?

Note: As described in Bug 384364, this bug causes double HTTP GET to URL specified in <a href>. It'll sometimes cause problem in server side PHP/JSP/ASP applications, if application don't have sufficient protection on "double GET/POST".

Comment 9

[WADA:World Anti-bad-Duping Agency]

Attachment: Test Case of LINK in FORM / FORM in LINK, with onClick/onSubmit/ACTION=javascript:/HREF=javascript/EventListener for click & submit

Problem of Bug 127903 doesn't occur with Fx 3 & Fx trunk, so both of "A HREF" and "FORM ACTION" are invoked when both "LINK in FORM" case and "FORM in LINK" case. And, when FORM is used, scheduling of load for ACTION/HREF can be postponed by alert() in onSubmit handler of FORM. Attached test case is to see when ACTION/HREF is scheduled.
See "Test Result" section in attached HTML for my test result.

Following is trace data for first schedule of "A HREF". 
> 18(194 msec) : (*1) HREF of link_34, load_count=1 (Alert is issued)
Following is trace data for second schedule of "A HREF". 
> 27(18383 msec) : (*3) HREF of link_34, load_count=3 (Alert is issued)

First schedule of "A HREF" looks to be a result of ususal link click.
Second schedule of "A HREF" seems to be a result of propagation of "Default Action" by click of "INPUT type=submit".
It looks that "BUTTON/INPUT type=button/reset" case is similar to "retrurn false case by onSubmit handler of FORM".

Comment 10

[WADA:World Anti-bad-Duping Agency]

Test procedure:
(0)Enable JavaScript
(1)Load the test HTML
(2)Check "Issue alert in onSubmit", "Issue alert in ACTION", "Issue alert in HREF"
(3)Click button
Before execute other case, please click "Clear message/Re-initialize data" button.