Bugzilla – Bug 122568
Firefox popup blocker
Last modified: 2006-08-16 05:57:22 UTC
Firefox ignores popup blocker settings. It still blocks popups when the popup blocker is turned off, and also ignores the allowed list. May be a firefox problem but it didn't occur in SuSE 9.3.
Do you know a site where this is reproducable?
Created attachment 54823 [details] picture of blocked pop-up window message although i switched off pop-up-blocking the shown error-message about a blocked window appeared.
i also have this bug. i have installed MozillaFirefox-1.0.7-0.1. please try online-banking. i created an attachment showing my online-banking-start-window with an error-message, that it had to block the online-banking-main-browser-window, although i switched off pop-up-blocking! but it seems to occour not on every pop-up-window. the pop-up-windows from novells support-request-document (https://secure-support.novell.com/eService_enu/) works. it, for example, opens pop-up-windows for "Entitlement" without any problems. it seems that it works, when the window has all properties enabled like menue-bar, status-bar, .... it seems that when the window has some things switched off then it gets blocked! so it seems to have to do something with the properties of the opened window. in mozilla everything works! (i have 1.7.12)
*** Bug 128943 has been marked as a duplicate of this bug. ***
Does it happen on a fresh profile?
i don't know if it would also happen on a fresh profile, but it happens on my existing profile, which i have since a long time. i used it under all suse 9.x versions with every for suse 9.x released version of firefox. there was never a problem. then i upgraded to suse 10.0. and there i upgrded firefox to 1.0.7-0.1. and then i noticed it.
i have tested now with fresh profile. but it is the same thing. regardless of profile it blocks pop-ups, even if pop-up-blocker is switched off. please fix this bug, coz firefox is unusable with it!
hello? is anybody out there?
Preparation of Firefox 1.5 is more important at the moment since it perhaps will be released as security update at some point for 10.0. So if you like you could check if Firefox 1.5, provided as test package from ftp://ftp.suse.com/pub/projects/mozilla/experimental/firefox/ fixes the problem. We are aware of the problem and we will work on it if there is time.
This version doesn't seem to have that popup blocker problem anymore
yes, i know that, but i didn't want to upgrade to this release-candidate because of installed extensions and possible new bugs of this release-candidate. ok, but after you told me the above, i installed 1.4.99-3.1 and the popup blocker problem is gone. i hope that there are not that many other bugs in this release-candidate.... thanks for help & info.
Robert, maybe we have to investigate this since we will most probably do a security update soon. If possible we should try to fix this. I'll also have a look.
I'm testing this, and I actually have the opposite problem! Firefox (1.0) isn't blocking popups even though my preferences say it should.
I built my own build of Firefox 1.0.7-0.1 and now I can't reproduce the problem :-(
I can no longer reproduce the problem at all.
Wolfgang, how about you?
I've seen the behaviour with our 1.0.7 package still. Also my colleagues see it everytime with 1.0.7 on 10.0. Did you built the current 1.0.7 package in autobuild or did you remove patches? I haven't seen the problem with the plain 1.0.7 sources IIRC. I'm back in the office on monday and can do further testing then.
I tried to build our autobuild package, without removing patches. Maybe I made a mistake. How hard would it be to push out a debuginfo package for 1.0.7?
For which distribution? I have debuginfo packages along with binary packages for 9.3-i386 and 10.0-i386 on ftp.suse.com/pub/projects/mozilla/firefox/1.0.7 I don't know if it's possible to create them for NLD9.
How about 10.0-x86-64 please? :-)
ftp://ftp.suse.com/pub/projects/mozilla/firefox/1.0.7/10.0-x86_64/*
I'm having a really tough time reproducing this. I can get it to happen once in a while but not very often. I tracked it as far as 'gPopupControlState' (a global variable) getting set to some really huge garbage value. Because of the logic in PushPopupControlState in nsGlobalWindow.cpp, it stays stuck at this value permanently and cause popup blocking settings to be ignored. Wolfgang, if you can reproduce reliably and care to venture in with gdb, do this: (gdb) break nsGlobalWindow.cpp:411 (gdb) condition 1 aState > 3 (gdb) c and let me know the stack trace you get when the breakpoint fires. Thanks!
I can reproduce it still every time. But the breakpoint didn't fire when it happened.
watching the gPopupControlState I see that it flips between openAbused and and 148677380 (in my case). aState in line 421 void PopPopupControlState(PopupControlState aState) is the wrong value. Backtrace while hitting this: #0 PopPopupControlState (aState=148677380) at nsGlobalWindow.cpp:422 #1 0x08219eda in PresShell::HandleEvent (this=0x8b49f80, aView=0x942afc0, aEvent=0xffffb430, aEventStatus=0xffffb34c, aForceHandle=1, aHandled=@0xffffb348) at nsPresShell.cpp:5921 #2 0x0836e7b9 in nsViewManager::HandleEvent (this=0x8f01730, aView=0x942afc0, aEvent=0xffffb430, aCaptured=0) at nsViewManager.cpp:2273 #3 0x08370120 in nsViewManager::DispatchEvent (this=0x8f01730, aEvent=0xffffb430, aStatus=0xffffb3f8) at nsViewManager.cpp:2061 #4 0x08369002 in HandleEvent (aEvent=0xffffb430) at nsView.cpp:74 #5 0x081fe29b in nsCommonWidget::DispatchEvent (this=0x8b44178, aEvent=0xffffb430, aStatus=@0xffffb478) at nsCommonWidget.cpp:215 #6 0x081f9dd3 in nsWindow::OnLeaveNotifyEvent (this=0x8b44178, aWidget=0x8aca7e0, aEvent=0x8b2dc80) at nsWindow.cpp:1311 #7 0x081f9dfd in leave_notify_event_cb (widget=0x8aca7e0, event=0x8b2dc80) at nsWindow.cpp:3264 #8 0x55841e60 in gtk_marshal_VOID__UINT_STRING () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #9 0x55b4bd19 in g_closure_invoke () from /opt/gnome/lib/libgobject-2.0.so.0 #10 0x55b5b816 in g_signal_stop_emission () from /opt/gnome/lib/libgobject-2.0.so.0 #11 0x55b5cbee in g_signal_emit_valist () from /opt/gnome/lib/libgobject-2.0.so.0 #12 0x55b5d1f5 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0 #13 0x559343b4 in gtk_widget_activate () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #14 0x558408a8 in gtk_main_do_event () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #15 0x55a46f8a in gdk_screen_get_setting () from /opt/gnome/lib/libgdk-x11-2.0.so.0 #16 0x55ba735c in g_main_context_dispatch () from /opt/gnome/lib/libglib-2.0.so.0 #17 0x55baa7cb in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0 #18 0x55baaae7 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0 #19 0x5583f861 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #20 0x081fdb1a in nsAppShell::Run (this=0x8a29090) at nsAppShell.cpp:142 #21 0x086f0180 in xre_main (argc=1, argv=0xffffc704, aAppData=0x86f88d0) at nsAppRunner.cpp:1981 #22 0x080810db in main (argc=1, argv=0xffffc704) at nsBrowserApp.cpp:58 #23 0x56121ea0 in __libc_start_main () from /lib/tls/libc.so.6 #24 0x08081031 in _start () at start.S:119
It sounds like nsAutoPopupStatePusher from nsPIDOMWindow.h is popping the wrong value, i.e., not the value it pushed. This is a bit disturbing since it's a very simple save-and-restore helper class. Would you mind adding a printf to the body of the constructor NS_AUTO_POPUP_STATE_PUSHER(PopupControlState aState, ...) to print the value of mOldState, and the value of 'this'? And another to the destructor before we call PopPopupControlState(mOldState) with the same data? I think inside the _IMPL_NS_LAYOUT #ifdef should be enough. mOldState should definitely *not* change between the construction and destruction of the same nsAutoPopupStatePusher. If it does, we're looking at memory corruption or a compiler bug.
Created attachment 72767 [details] that's the output of the printf proposal when mOldState switches the first time to the wrong value destruct: mOldState = 0 ; this = -19592 destruct: mOldState = 148676556 ; this = -18416 It does this in a destructor for an object never touched before during Firefox runtime.
Now I'm scared. Would you mind trying compiling nsPresShell.cpp with optimization off?
Also, gcc -S on nsPresShell.cpp would be useful.
I've compiled the whole codebase now without "-Os -march=i586 -mcpu=i686". It still shows the same behaviour.
Created attachment 73096 [details] nsPresShell.S
That disassembly looks OK. I don't know if that makes me happy or not. I think I'd like to see the gdb trace that you did in comment #24, but for the debug build, and the values of locals in HandleEventInternal if that's on the stack. Thanks for all the help.
I can't reproduce this on NLD9 (x86) or SLED 10beta9 (x86-64). This sucks.
Fixed with update to FF 1.5.0.x