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.