> ------- Additional Comment #1 From Jason Bassford 2002-07-24 05:47 ------- > >> 1. A named target in a link or form submission >> -- is it a request? (didn't we have a pref for this >> at some point? Should it only be a request if called via a >> user action (i.e. stopping bug 152007) > > The question is, is the user aware that this will happen when they submit the > form, etc.? The site may not inform of the fact that this other thing will > happen, in which case I think it would be unrequested. But, then again, they > might tell the user in the text of the form or elsewhere on the site, in which > case the user would be perfectly aware of the consequences of submitting the > form, and the window WOULD be requested. > > But from a programmatic standpoint, Mozilla can't determine if the user has > become aware of this behaviour or not. (Even if there is text on the site > describing what will happen, the user may have gone ahead without reading it.) > > Therefore, we only have three options as I see it: > > 1. Allow for gradients of enforcement in the pref where "strict" enforcement > blocks everything like this without question, and "standard" enforcement lets it > through. > > 2. Pop up a dialogue box in such a case asking if the user wants the window or > not - since Mozilla is unable to determine on its own what to do. > > 3. Either block all such windows, or allow all such window to be created. > > At a more general level, any of the above could also be linked into preferences > on a site by site basis. (But that shouldn't determine which approach we decide > on.) >
I think we already have a pref (or at least we did...) that blocked the ability to open a link into a target (along with form submission.) I am not sure what happened with that, or if it ever existed, but we should not make it a part of unrequested windows. It is by itself a different issue since many times it is required... Many banks will submit your data with the result in a seperate window to a secure href leaving your other window available for insecure navigation of their website. THere is also valid use of new-window links on news and government sites to signify that the page if offsite (and not endorsed by the org.) the problem comes (in bug 152007) where a body onLoad event handler submits a form to a named target, thereby opening a new window. It is a very resourceful workaround, and if I was in the habit of complimenting the devil, I would say it was ingenious. Is there a way to stop this itself? do we disable form submits in onloads? (interesting idea, but probably too restrictive.) Do we popup a dialog in this instance? (This page is submitting a form without your permission into a new window... continue? -- ehhh maybe, but I hate dialogs and most people ignore them.) or do we modify the target when the form submit is called via an "unrequested" eventhandler to point to the current window? (I would support this, but it woud mean that the page would send you elsewhere when they were intending to give you a popup. You would never be able to view the page you wanted.) *sigh* this part may be one situation we can't workaround. --Mike Young
smime.p7s
Description: S/MIME Cryptographic Signature
