Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 207900 - - the target attribute in the form element is ignored
: - the target attribute in the form element is ignored
Product: Tech Evangelism Graveyard
Classification: Graveyard
Component: German (show other bugs)
: unspecified
: x86 Windows 2000
: -- normal
: ---
Assigned To: german
Depends on:
  Show dependency treegraph
Reported: 2003-06-01 14:47 PDT by PsychoTekk
Modified: 2015-04-19 23:45 PDT (History)
2 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description PsychoTekk 2003-06-01 14:47:04 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030514 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030514 Mozilla Firebird/0.6

the menu frame of contains a form that is targeted to the main
frame. when submitting mozilla firebird does not show the page in the mainframe
but seems to do nothing. only when using directly,
the page is opened in a new window.

Reproducible: Always

Steps to Reproduce:
1.enter any username into the form
Actual Results:  
the request is submitted (and the form is reset by onSubmit="history.go()" as

Expected Results:  
the request should be submitted and the content displayed in the targeted main frame

according to the w3c standarts the target attribute is appropriate for form
elements (although not listed on the form page directly) and validates
Comment 1 Erik 2003-06-01 22:58:13 PDT
Using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030601 Mozilla
Firebird/0.6 I can confirm the following:

- using the given URI and entering any username and pressing Login the page 
reloads but nothing else happens
- using the direct URI to the menu the error page "you do not have permission to
perform this action" shows up after entering any username and pressing Login

Nevertheless this behaviour occurs also when using SeaMonkey Gecko/20030601, so 
if at all this is probably a Browser issue and should be filed accordingly. I 
had a quick look in related Browser bugs but didn't found a duplicate one but 
since there are many bug reports which may be related someone else should do an 
additional search.
Comment 2 Erik 2003-06-02 23:47:02 PDT
Well, after some additional searches for possible dupes I didn't found a related
SeaMonkey bug 

=> reassigning to "Browser / Layout: Form Controls" for further investigation
Comment 3 Erik 2003-06-02 23:48:45 PDT
reassigning owner & QA contact
Comment 4 Wolfgang Schwarz 2003-10-26 15:00:18 PST
The form tag has the attribute
and that causes the frame to be reloaded before the form is submitted. (Seems
that Mozilla interprets the somewhat obscure history.go() as history.go(0).)

I'm not sure if there is an official rule how browsers are supposed to handle
situations like this, where onsubmit changes the location of the current window
but the default reaction to the submission event is not suppressed (by returning
false): Should the form be submitted or not? If there is an official rule then
Mozilla breaks it because it really behaves differently depending on whether the
page is in the frameset or not.

(BTW, I'm seeing this with Mozilla 1.5 (20030929) on Linux/PPC, so if it's
really a bug then it's All/All, not PC/Win2000.)
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2003-12-06 23:27:20 PST
This has nothing to do with form controls... but in any case, our behavior is
now completely consistent -- frameset or no frameset, reloading that page via
history.go() prevents the form submission over here, as it should.

Over to evang.
Comment 6 Cyrille VIVION 2004-08-18 04:33:37 PDT
Comment 7 Matthias Versen [:Matti] 2009-02-16 11:27:28 PST
owned by domain grabber

Note You need to log in before you can comment on or make changes to this bug.