Open Bug 331635 Opened 16 years ago Updated 4 years ago
Embeddors can't force-show (unblock) a blocked popup
I was trying to implement an "Unblock" feature in the new popup blocking notification UI in Camino. So, basically the approach was the same as Firefox today. 1. Cache the nsIDOMPopupBlocked event, with all its useful info. 2. If the user wants to unblock the popups from the site, iterate over them and open popups using nsIDOMWindowInternal::Open() However, for us, the popups are yet again blocked! nsGlobalWindow::OpenInternal() has some code where it checks whether the popup is "abusive", and decides to block it. So to sum up: we need some sort of API that could force-show a popup, or even a built-in interface for doing Unblocking? As it stands now, we have to traverse the docshell tree and what-not, perhaps that could be made simpler?
Here is where Firefox's unblock logic is: http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#430 and see the dependent bug for my approach, which was the same, but from C++.
What's the difference between what Firefox does, and what you're trying to do? i.e., where is it failing in OpenInternal?
Boris mentioned it probably has to do with the fact that Firefox is done in XUL, so a click is dispatched along with the Open() call, which makes Gecko understand that it's something the user wants. Since Camino's code is all objective C, all gecko gets is a Open() call, and thus it blocks us.
So we do have a method to do this on nsPIDOMWindow (the one plugin code uses). But that's not really an API we want embeddors using. jst, what's a reasonable way to expose this on an embedding-accessible API? And do we just want to expose the override, or do we want to allow embeddors to use a codepath similar to the presshell's (the one that pushes the popup state based on the event coming through)?
Just FYI, we're using the popup state pushing as a workaround right now in Camino.
Flags: blocking1.9a1? → blocking1.9-
Need API proposal or something. I'm not sure I can think of anyone who has time to do this right now, so whoever needs this should spend some time on coming up with an API proposal.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.