359597 - Showing popups doesn't work from Tools menu

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Stefan [:stefanh]]

SeaMonkey trunk and branch, Mac OS 10.3.9.

Showing popups from Tools --> Manage Popups doesn't work on mac. The context menu from the statusbar icon works, though.

Steps to reproduce:

1) Load http://www.popuptest.com/popuptest1.html with popups blocked.
2) Select one of the popups in Tools --> manage Popups.

--> The popup doesn't load.

3) Now, right-click (or Ctrl-click) on the popup icon in the  statusbar and select one  of the popups.

--> The popups loads.

Note that trying 3) on trunk could be problematic since, in some cases, our context menus seems pretty broken (in this case ctrl-click seems to be interpreted as left-click) - luckily I had a fresh tree with toolkit=mac ;-).

I've  been looking at function popupBlockerMenuCommand(target) at suite/browser/navigator.js#2449 to see what's happening here. Everything seems to be OK (uri and features are there) except that window.content.open(...) doesn't seems to work if you call it from the Tools menu. Could this be related to the fact that mac uses native menus?  Can we replace window.content,open(...) with something else?

Comment 1

[[e-mail]]

CCing Boris as I don't want to rashly blame Mac widget code for this ;-)

stefan, could you try changing permissionsNavigatorOverlay.xul to read
oncommand="setTimeout(popupBlockerMenuCommand, 0, event.target);"

Comment 2

[Boris Zbarsky [:bzbarsky]]

> except that window.content.open(...) doesn't seems to work if you call it from
> the Tools menu.

Can you step down into nsGlobalWindow::Open ?  Are you just geting popup-blocked again due to this not happening inside a "Gecko" window?

> Could this be related to the fact that mac uses native menus?

Which means that Gecko might not be seeing any user input as you do this?  Absolutely could!  See above.

Comment 3

[Stefan [:stefanh]]

(In reply to comment #1)
> CCing Boris as I don't want to rashly blame Mac widget code for this ;-)
> 
> stefan, could you try changing permissionsNavigatorOverlay.xul to read
> oncommand="setTimeout(popupBlockerMenuCommand, 0, event.target);"
> 

No change here.

Comment 4

[Stefan [:stefanh]]

(In reply to comment #2)
> > except that window.content.open(...) doesn't seems to work if you call it from
> > the Tools menu.
> 
> Can you step down into nsGlobalWindow::Open ?  Are you just geting
> popup-blocked again due to this not happening inside a "Gecko" window?
> 
> > Could this be related to the fact that mac uses native menus?
> 
> Which means that Gecko might not be seeing any user input as you do this? 
> Absolutely could!  See above.
> 

It's food time here, I'll try and look at it later/ or tomorrow. Sounds that the issue is nothing that will get resolved on branch, no (thinking of approvals etc)?

Comment 5

[[e-mail]]

(In reply to comment #3)
>>stefan, could you try changing permissionsNavigatorOverlay.xul to read
>>oncommand="setTimeout(popupBlockerMenuCommand, 0, event.target);"
>No change here.
That makes sense given comment 2, but to be sure you would need to debug nsGlobalWindow::Open to see if your popup gets blocked again.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Sounds that the issue is nothing that will get resolved on branch

"depends".  If I'm right about the problem, it's a pretty serious issue for all embeddors and we probably _should_ resolve it on branch.

Comment 7

[Stefan [:stefanh]]

OK, I'm having some trouble debugging this - let's say it's a combination of not knowing enough and that gdb randomly reports "Timed out fetching data. Variable display may be inaccurate." (It's actually the ancient Xcode 1.5 since I'm on 10.3.9).

Anyway, I was looking a bit at nsGlobalWindow::CheckOpenAllow. It returns allowNot if I try to open a popup from the Tools menu. In nsGlobalWindow::FireAbuseEvents, ablocked = 1 and aWindow = 0.

If I add the site to the list of allowed sites and then try to open the popup from the Tools menu, nsGlobalWindow::CheckOpenAllow is returning allowWhitelistened and the popup opens.


I don't know if this takes us any further, though.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oh, it does.  It shows that your attempt to open the window is in fact getting blocked by the popup blocker.

I wonder... is this and issue in Firefox too?  Or does Firefox just not have a menu option for this?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> I wonder... is this and issue in Firefox too?  Or does Firefox just not have a
> menu option for this?

Firefox has the status bar icon and a notification box menu, but no options for it in the main window menu, so sounds like this doesn't affect Firefox.

Comment 10

[Boris Zbarsky [:bzbarsky]]

OK.  So does the menu in Seamonkey run JS code?  If so, we need to bite the bullet and fix bug 331635.  With a nice scriptable interface.  Perhaps a method off nsIDOMWindowUtils?  Or something more frozen?

Comment 11

[Stefan [:stefanh]]

We should remove the part that doesn't work for mac users.

Comment 12

[Robert Kaiser]

OK, after talk with Mnyromyr, it's our opinion that it's not nice but it doesn't need to block the release. A patch (workaround?) would probably be appreciated for 1.1.x though.

Comment 13

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 14

[Cecelia S]

Just an update, this bug still exists in SeaMonkey 2.0. The show popup option in the menu from the "Preferences" button of the popup blocker banner also doesn't work.

Comment 15

[Stefan [:stefanh]]

(In reply to comment #14)
> The show popup option
> in the menu from the "Preferences" button of the popup blocker banner also
> doesn't work.

That works for me with the 2.0 release (mac).

Comment 16

[Stefan [:stefanh]]

Cecelia,

If you have found any issues with the show popup option in some other places than the tools menu, please file a separate bug (so it doesn't get lost). The issue here is related to the fact that the tools menu is in the "main" menu.