User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061006 Camino/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061006 Camino/1.0+ In this popup test, camino blocks the popup, but does not display notification of such Reproducible: Always Steps to Reproduce: 1. request http://www.popuptest.com/popuptest3.html 2. wait 5 seconds Actual Results: Nothing Expected Results: Notification of popup being blocked This worked as expected in Firefox 126.96.36.199
For reference, that page launches timed popups every 5 seconds. I see this too. Is it possible that this is just bug 333284 in another guise?
I think this is different from bug 333284, since here we never see the notification at all. This works on the 1.8.0 branch (and in Fx 2 as well). Håkan, what all have we changed that would have affected this? It seems like fairly simple JS throwing the popup.
Does it work in Camino-1.8? Does it work in Firefox trunk? It might be a gecko change. If someone wants to debug it, set a breakpoint in the method in the CHBrowser code, where we handle the nsIDOMPopupBlockedEvent, and see if it's even fired for this page... If it is, it's our bug, if it's not, it's not our bug. :)
- Works on today's Minefield - Broken on Camino on both 1.8 branch and trunk - Worked with the old popup blocker (ie on Camino 1.0.3) - Yes, that method gets called ie, it's definitely our bug.
This is working on trunk (2006101622) for me now, as is davedit's testcase in comment 5. cl
The issue here is that we always defer the blocker display until the pageload finishes, which doesn't work so well for popups that are triggered after the page finishes loading. We'll need to defer only while the page is loading, not after. Taking.
*** Bug 357642 has been marked as a duplicate of this bug. ***
Created attachment 243286 [details] [diff] [review] removes delayed display Per our discussion, removes the delay entirely to prevent potential issues with very slow-loading pages. We'll keep our eyes peeled for issues that would make bringing back the delay for popups thrown during load necessary. The bulk of this change is just moving code unmodified, so it's actually a very small change. As an added bonus, it stops leaking all the blocker notification views.
+ [mBlockedPopupView release]; // retain count of 1 from nib why do we need this? are we leaking it? shouldn't it go away when the nib goes away?
(In reply to comment #10) > + [mBlockedPopupView release]; // retain count of 1 from nib > > why do we need this? are we leaking it? Per IRC discussion, yes.
Comment on attachment 243286 [details] [diff] [review] removes delayed display sr=pink
Checked in on trunk and MOZILLA_1_8_BRANCH