Submit HTML form to _blank without popup blocker



  • I may post the full story to the sidebar sometime since it's basically http://xkcd.com/1172/ in the flesh. In the meantime I'm hoping to find a sensible solution that will make everyone happy. However this is the first truly major jaw-dropping WTF moment I've had at my current job.

    Without getting into too many details, if I can find one workaround to something I might be able to get by without doing some really retarded crap. So here's what I need.

    I have an HTML form element with hidden input fields that POSTs data to an ASP.NET page which must open in a new tab. It must be in a new tab because the current tab is a Silverlight application with lots of state, ending the Silverlight app is not acceptable. It must be a POST request because there is too much information to transmit via GET. The form submit is actually submitted by our Silverlight code via the Silverlight-JavaScript bridge and calls . This is universally blocked by popup blockers, however if the user enables popups for the site (a one-time change) it works just fine.

    Here's the issue. [client name redacted] has some kind of security in place that prevents the user from allowing popups and [client name redacted] refuses to correct that. Is there some way to trigger a form submit to a new tab without triggering the popup blocker?

    <form id="myForm" action="somePage.aspx" method="post" target="_blank">

        <input type="hidden" value="lots of encoded data to post to somePage.aspx"/>

    </form>

    The Silverlight code calls an on-page JavaScript function which sets a couple things in the form and then calls document.getElementById("myForm").submit()

    Any ideas on how to prevent the popup blocker? I realize this might not be possible, but the alternatives involve accelerated balding, hypertension, and probable loss of [client name redacted] as a client when the proposed "fix" doesn't work. ("Fix" involves rolling back to a super-buggy and unreliable original implementation of this feature that did not work for 90%+ of our users, and so stands a very good chance of not working for [client name redacted]. I seem to be the only one who understands this.)



  • User-initiated popups are not blocked. You're going to have to get the user to click on a bit of html.

    Then again, I sometimes get banners opening windows all on their own, so you could inquire about their shady methods.



  • What Dhromed says, the pop-up has to be a direct result of user action. (Translation: the pop-up has to be created in the "onclick" or "onkeydown" event handler after the link is activated.)

    If you can make that happen, you're golden. Do you have to do the post as part of a form submission, or can you AJAX it? (i.e. are you POSTing to the same domain or not?)



  • @blakeyrat said:

    Do you have to do the post as part of a form submission, or can you AJAX it? (i.e. are you POSTing to the same domain or not?)

    He could always use the click to pop the new tab, then push his form data into a hidden form in the new tab and submit it.



  • It doesn't have to be a form submission, I could AJAX it to some server-side .NET code. But the app still has to open the resulting page/data in a new tab, which still counts as a popup.

    I added an HTML button above the Silverlight control as a proof-of-concept. Now you have to do some stuff in Silverlight to generate the form, then click the HTML submit button that's in the form, however it does bypass the popup blocker. The higher-ups decided that that's too many clicks. I can probably refine the solution some more but that would involve switching Silverlight to so-called "windowless" mode which massacres the graphical performance of the app.

    I get the feeling [client name redacted] has some serious internal politicking going on and that there is a faction that doesn't like us and so refuses to be pleased. I just hope that all the crap doesn't roll on me since I'm lead developer for this project.



  • @morbiuswilters said:

    @blakeyrat said:
    Do you have to do the post as part of a form submission, or can you AJAX it? (i.e. are you POSTing to the same domain or not?)

    He could always use the click to pop the new tab, then push his form data into a hidden form in the new tab and submit it.

    That, or send a synchronous AJAX request so you're technically still in the handler when the data gets returned and you can open the new window. (Yes it's a bad user experience, but it sounds like this app is already awful.)

    Actually Morbs' idea is easier and "better". Use it.



  • @morbiuswilters said:

    @blakeyrat said:
    Do you have to do the post as part of a form submission, or can you AJAX it? (i.e. are you POSTing to the same domain or not?)

    He could always use the click to pop the new tab, then push his form data into a hidden form in the new tab and submit it.

     

    I'm not following...the clicks come from Silverlight, not an HTML element. Otherwise it wouldn't be an issue.



  • @mott555 said:

    I'm not following...the clicks come from Silverlight, not an HTML element. Otherwise it wouldn't be an issue.

    Clicks bubble.

    ... I guess do you need more explanation than that?



  • @mott555 said:

    @morbiuswilters said:

    @blakeyrat said:
    Do you have to do the post as part of a form submission, or can you AJAX it? (i.e. are you POSTing to the same domain or not?)

    He could always use the click to pop the new tab, then push his form data into a hidden form in the new tab and submit it.

     

    I'm not following...the clicks come from Silverlight, not an HTML element. Otherwise it wouldn't be an issue.

    Can you have Silverlight "click" an HTML element that will pop open the tab? I don't know if that will bypass the browser's pop-up blocker. Otherwise, you're probably going to have to get the user to click on an HTML element. I've never used Silverlight--could you make an invisible div that sits above the button/link/whatever in Silverlight so that when the user goes to click it it's actually picked up by the HTML element? (So basically clickjacking your own users. Hideous, but I've done this in the past for other, hacky projects..) I don't know if SIlverlight and/or modern browsers let you get away with that.



  • @morbiuswilters said:

    So basically clickjacking your own users. Hideous, but I've done this in the past for other, hacky projects..
     

    I've done this once as well.

     

    With a library like jQuery, you can call the click() event programmatically,  but I haven't delved into its internals, and I don't know if browsers will let it open new windows.



  • @dhromed said:

    @morbiuswilters said:

    So basically clickjacking your own users. Hideous, but I've done this in the past for other, hacky projects..
     

    I've done this once as well.

     

    With a library like jQuery, you can call the click() event programmatically,  but I haven't delved into its internals, and I don't know if browsers will let it open new windows.

    You can emulate a click in just normal DOM, too. You can't avoid the popup blocker that way, though.



  • Tried that already. Yes you can use JavaScript to trigger a click, but it still triggers the popup blocker.

    It sounds like some coworkers are going to try to convince [client name redacted] to disable their popup blockers for our site. And if they won't do it themselves, we're going to suggest letting us remote into all their systems and fix it for them.



  • @dhromed said:

    With a library like jQuery, you can call the click() event programmatically,  but I haven't delved into its internals, and I don't know if browsers will let it open new windows.

    Apparently you can't, but I'd think you could still do the "invisible div floating over Silverlight" trick.



  • @morbiuswilters said:

    Apparently you can't, but I'd think you could still do the "invisible div floating over Silverlight" trick.

    Why would you have to? Clicks bubble! Am I the only one who understands how DOM events work?



  • @blakeyrat said:

    That, or send a synchronous AJAX request so you're technically still in the handler when the data gets returned and you can open the new window.

    I'm just curious (and haven't checked it), does that really work? Because that would mean that popup protection works across callbacks - which would make the whole point pretty pointless.

    As a spammer, I could just do

    someLegitimateButton.onclick = function() { setInterval(openViagraPopup, 10000); }
    and game the whole thing. Am I missing something?



  • @blakeyrat said:

    Why would you have to? Clicks bubble! Am I the only one who understands how DOM events work?
     

    What difference does it make that events bubble?



  • @PSWorx said:

    I'm just curious (and haven't checked it), does that really work? Because that would mean that popup protection works across callbacks

    Nooooo. That's why I said use a synchronous AJAX request. Unless I've once-again reversed the definition of "synchronous" and "async"... (looks it up) ok no I'm good. So now I can act smug and condescending.

    READ MY POST BEFORE REPLYING YOU CRETIN IDIOT MORON MAN DUMMY!

    @PSWorx said:

    As a spammer, I could just do

    someLegitimateButton.onclick = function() { setInterval(openViagraPopup, 10000); }
    and game the whole thing. Am I missing something?

    Two things:

    1) Spammers generally don't have the ability to inject code into the page, and if you *do* have that ability (i.e. you've cracked the web server open or you've installed a toolbar on-the-sly) you can do much more invasive and annoying shit anyway.

    2) Your code won't work anyway because it's an async call; you leave the click handler long before the AJAX request fires off it's "data received" event. And even if your AJAX was incredibly fast so that wasn't true, the "data received" event isn't allowed to create pop-ups anyway (since it's not a direct response to user action) so it wouldn't matter.



  • @dhromed said:

    What difference does it make that events bubble?

    You have the Silverlight set a global JS variable like "window.thisIsAFormSubmitClick" when it's handling the click event, then when it bubbles up to the document level you can have another click handler that does stuff based on that global JS variable.

    You people are acting as if once Silverlight handles the click event it disappears into the ether-- it doesn't (unless you specifically tell it to not bubble, of course.) The same click event goes to every other level of the DOM, and you can handle it again at any one of those. So the event handler you installed on Document can handle the same click event your Silverlight just handled a millisecond ago. (And since it's an event in direct response to user action, you can do your pop-up thang at that point.)



  • @blakeyrat said:

    @morbiuswilters said:
    Apparently you can't, but I'd think you could still do the "invisible div floating over Silverlight" trick.

    Why would you have to? Clicks bubble! Am I the only one who understands how DOM events work?

    I just assumed Silverlight wouldn't bubble clicks out to the normal DOM.



  • @morbiuswilters said:

    I just assumed Silverlight wouldn't bubble clicks out to the normal DOM.

    Why wouldn't it? Even Flash manages that, and Flash is a complete piece of shit.



  • @blakeyrat said:

    @morbiuswilters said:
    I just assumed Silverlight wouldn't bubble clicks out to the normal DOM.

    Why wouldn't it? Even Flash manages that, and Flash is a complete piece of shit.

     

     

    are you plain retard or just act like that on internet? flash is good.



  • @Nagesh said:

    are you plain retard or just act like that on internet?

    I'm just Internet Retard. In real life I'm a successful lawyer living in San Jose, CA.



  • @Nagesh said:

    Filed under: flash = good.

    Am I the only one who finds it hilarious that the three things Nagesh vociferously defends--Apple, Java and Flash--are notoriously at cross-purposes?



  • @blakeyrat said:

    @morbiuswilters said:
    I just assumed Silverlight wouldn't bubble clicks out to the normal DOM.

    Why wouldn't it? Even Flash manages that, and Flash is a complete piece of shit.

    I'll level: I did not know Flash could do that. Although my company does a lot with Flash, I've never directly had to do anything with it. In fact, I usually browse with it disabled.



  • @blakeyrat said:

    @PSWorx said:
    I'm just curious (and haven't checked it), does that really work? Because that would mean that popup protection works across callbacks

    Nooooo. That's why I said use a synchronous AJAX request. Unless I've once-again reversed the definition of "synchronous" and "async"... (looks it up) ok no I'm good. So now I can act smug and condescending.

    READ MY POST BEFORE REPLYING YOU CRETIN IDIOT MORON MAN DUMMY!

    Eh... synchronous - asynchronous... it's just a single letter... I can't be bothered to read every single letter you write before quoting you after all... @blakeyrat said:
    Two things:

    1) Spammers generally don't have the ability to inject code into the page, and if you *do* have that ability (i.e. you've cracked the web server open or you've installed a toolbar on-the-sly) you can do much more invasive and annoying shit anyway.

    I assumed in the example that the popup code was on the site with full permission of the owner - because the code probably came from one of the more morally flexible ad networks or somesuch which paid the owner good money to put it on the site. After all, the whole mechanism is there to protect users, not site owners.

    @blakeyrat said:

    2) Your code won't work anyway because it's an async call; you leave the click handler long before the AJAX request fires off it's "data received" event. And even if your AJAX was incredibly fast so that wasn't true, the "data received" event isn't allowed to create pop-ups anyway (since it's not a direct response to user action) so it wouldn't matter.

    Well, that was the exact point I was trying to make. If an async callback could "inherit" the permission from a user event, the whole thing would be useless. But since that was never stated, this whole example is moot now. I'm sad.


  • @PSWorx said:

    I assumed in the example that the popup code was on the site with full permission of the owner - because the code probably came from one of the more morally flexible ad networks or somesuch which paid the owner good money to put it on the site. After all, the whole mechanism is there to protect users, not site owners.

    Mortally flexible ad networks are only used by morally flexible websites. I.e.: no porn, no bad ads.


Log in to reply