So, I was working on a project the other day that authenticated users via LinkedIn and it was using a popup window.
The team I was working with noticed that usually Chrome (among others) was blocking the popup I was calling via Javascript. Here was the flow of logic:
Thanks to these two posts on StackOverflow, I realized that the problem was Chrome (among others) was blocking popups that weren’t a direct-result of a user’s action.
Smart popup blockers will allow a popup if it is directly associated to a user’s action. If it’s delayed in anyway, there’s a good chance it’s going to get blocked.
In this case, it was a result of a user’s action, but the call to window.open()
wasn’t happening until the success
callback of my jQuery.ajax()
call was fired. This meant it was asynchronous and Chrome was suspicious.
So, I decided to change my flow to this:
location
property (basically, redirects our allowed popup)Note: as a best practice, I informed the user on the intermediary page that I’m redirecting them and provided an HTML link within that intermediary page should the redirection Javascript fail. I feel this is a good practice for positive user-experience and nice fall back should shit hit the fan with Javascript/browser settings.
Note: ajaxurl
has been defined as the absolute URI to my WordPress AJAX script:
jQuery(document).ready(function($){ $(".signin").click(function(){ var w = window.open( ajaxurl + '?action=andy_intermediary_html' ); $.ajax({ url: ajaxurl, data: { some_var : "Something", another_var : "Something else" }, // remember, this request is just returning the URL we need. success: function( data ) { w.location = data; } }); return false; }); });
Make sure your popups are a direct result of a user’s action, if not, popup it up during the trigger action and make changes as needed after the fact. You’ll stay in the blocker’s good graces.
Hope this helps you out. Thanks!
RSS feed for comments on this post. TrackBack URL
Otto says…
Why not cut out the middle-man of the AJAX request there, and make the link they’ll need before-hand, then open the window directly?
Might be a reason to do this, I grant you, but probably not one that couldn’t reasonably be eliminated and thus make the code simpler overall.
andy says…
Totally agree. Effectively I was told we had to generate the LinkedIn authentication URL in real-time, i.e. if we did it at page load and users sat for a few minutes and then clicked, it could be invalid (I’m not working directly with the API instead with a wrapper plugin another dev wrote).
Not sure if it can be eliminated or not – but was based on requirements I was given. Definitely would want it much simpler!
grena says…
Thank you for your explanations.
It helped me a lot to understand this issue 😉
Joker69 says…
Dude, you are amazing!!!! I’ve been battling for a couple of days now!!!!! Thanks
Marcos Schlucat Grimm says…
Thanks for the explanation.
I did something different, as I use document.write function to write to the new window. So I opened the window befor the ajax, and passed it to the returning function as a parameter