Open Bug 245920 Opened 20 years ago Updated 16 years ago

manually opening a blocked popup doesn't work for form submits

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: mvl, Unassigned)

Details

from bug 198846 comment 40:

if a popup is opened like this:

<body onload="document.foo.submit()">
  <form name="foo" target="_blank" method="post" action="whatever">
    <!-- form elements here -->
  </form>
</body>

manually opening it won't work, because that simply uses window.open(), and
passes in a url. So, it looses the form data.
Basically, I think we need a "private" method on windows that we can use to do
an  "open and load" of arbitrary content (including form post data, etc) as a
single operation.  If the open is blocked, the load will be blocked too and the
event can include pointers to enough information to recreate the load (post
data, referrer, uri, etc).

Dan, what do you think?  I know we have existing bugs due to the fact that
docshell just uses window.open to open the new window for targeted loads...
Color me sleeping, but I thought targeted loads worked well. And since
window.open() already takes an URL to load, I can't think of anything to add
except, I guess, form post data. But do we need a new window opening API to
implement that? (I don't know! I'm not completely clear on how that whole
process is carried out.) openDialog already takes an arbitrary extra data
reference. Referrer in the context of bug 198846 is already available. Guess I
haven't been thinking about this enough.
Targeted loads work OK as long as you don't try to block popups.  I recall us
having issues with target="_blank" links (popup blocker blocking things it
shouldn't), but those may have been fixed.

> I can't think of anything to add except, I guess, form post data.

Exactly what this bug is about!  ;)

> But do we need a new window opening API to implement that? (I don't know! I'm
> not completely clear on how that whole process is carried out.)

Right now, docshell just calls vanilla window.open() with "about:blank" as the
URI to create the new window, then gets its docshell and retargets the load to it.

Note that this means when the open() is blocked the URI it's looking at is
"about:blank" and there is no post data in sight.

If we do have a window-opening function that allows passing in post data,
referrer, and URI, we should be using it in docshell... if not, I'm not sure how
to fix this issue short of adding one.
Ah. Well I'm not keeping up with bugs so much these days, so I'm probably off.
But I'm not aware of the popup blocker blocking anything it shouldn't because of
a "_blank" target. Doesn't mean it's not doing it.

I can think of two approaches.
(1) The one you're suggesting: carry the post data through to the actual window
opening function so it can be included in the PopupBlocked DOM event, as the
URIs and Features are now. (2) After the docshell realizes there's no target for
this load, emit some kind of secondary PopupBlocked event containing the post data.

In either case we'll have to make a similar modification to the DOM event, so we
can omit that from consideration when trying to pick a course. Course (1)
requires that the post data be carried through a couple of levels of API where
it really doesn't belong. nsDocShell::FindTarget comes to mind. It's doable and
safe enough, but a little unclean. Course (2) messes up the clean PopupBlocked
event interface, requiring that the event listener understand it may need to
merge multiple DOM events for one blocked window.

Neither is completely guilt-free. But I think I'd prefer (2). I suggest adding
two fields to nsIDOMPopupBlockedEvent: the post data, and a bit indicating
whether it's a primary or supplemental event. The post data field has to be
added in any case. Course (2) also has the advantage that it lays some
groundwork for fixing bug 235450. 235450 is much more difficult and we may
decide not to fix it at all, but I think something like course (2) is the
beginnings of the only possible approach.
Oh. You were probably thinking of the part that comes after. The UI has all the
data it needs to reconstruct the open and load, but no one to tell it to. We
should be able to construct an nsIDocShellLoadInfo and hand it off to the
content window's docshell from script, but maybe a cleaner interface is called for.
Hmm.. Yeah, having supplemental events posted by the docshell would probably 
work too.  I'm not familiar enough with all the targeting junk yet to decide
which approach is better.
Product: Core → Mozilla Application Suite
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.