Broken off from bug 75371, where people keep asking for an "Ask Me" preference for JavaScript functions. There seems to be no back end for this, so I'm filing a bug for it. Will file a seperate bug for front end. (Forgive me if this is the wrong component.)

cc'ing Boris - is this the right component?

Over to caps

Ask me is one option we definitely need, but it should also be possible to specify this on a site by site basis, along the lines of DENY all ALLOW lovelysite.com ALLOW interesting.org ALLOW useful.net

Diego, you can do that already. That's exactly how the current system works.

I don't get it. Am I the only one who thinks that popping up a window to ask the user if it's OK for the site to pop up a window is just nutty? Dialogs detract from the browsing experience and should be avoided, which is why I don't want an Ask Me setting. I'd much rather see a good pref panel where people can set which sites should be on the no-popups list, and maybe a menu item like the Cookie Manager one: "Block Popups From This Site." A menu item that's always available is better than a confirmation dialog - a 'tell,' not an 'ask.' There are a lot of opinions on UI design for popup blocking. Rather than file a whole bunch of bugs, each giving a particualr opinion, I think we should work out a good overall solution, maybe in the newsgroup (n.p.m.security maybe). I'd like to amrk this WONTFIX, but let's hear some comment first.

Mitchell, asking for window.open() makes no sense indeed. But it may make sense to ask for window.resizeTo(), for example. That said, I think I agree that this should be wontfix and that a decent UI should be implemented to allow easy setting of these prefs.

IMHO, the "ask me" option (with "remember this decision for this host") would be really useful. It is the most convenient way of populating the per-host access list. After browsing with "ask me" for a while, it may be a good idea to switch it off, but having an "ask me" option is still very useful.

Ask me does have its advantages, so it should maybe be possible as an option, although I second the notion that a good gui should be available. There should be a unified solution that covers cookies as well.

Aleksey, Don't you think a menu item would be just as convenient as a dialog (which is just another form of pop-up window)?

> Don't you think a menu item would be just as convenient as a dialog What kind of menu do you mean? The difference is that I have to activate the menu, while the dialog comes at me itself, so with dialog I have one less thing to do. Also, with menu, I need to have some way of knowing that a particular page wanted the pop-up and I do not see how the menu would do that... > (which is just another form of pop-up window)? No! With "remember this secision" you will see the dialog only once. Also, the dialog wouldn't eat you bandwidth :-)

Aleksey, I respectfully disagree, but I'm not a UI designer. Before we go adding features left and right, let's work out a complete design for popup-and-annoying-content blocking UI and get some real design advice.

Marking wontfix.

Marking verified Wontfix as per above developer comments.

*** Bug 112006 has been marked as a duplicate of this bug. ***

Why is this marked as "WONTFIX"? This is still an issue. This is a user requesting an Ask Me preference. I like comment #5 and #7 ideas of a cookie-like dialog, but this is still a request. If there is another bug for this, that's fine, but otherwise, this should not be set to WONTFIX, especially if duplicates are being marked for this request.

Um... Please read the definition of WONTFIX (http://bugzilla.mozilla.org/bug_status.html). There is no reason why this should not be WONTFIX (are you confusing WONTFIX and INVALID?). This may be an "issue" but the component owner has made a design decision which he believes will best serve the needs of users overall and will most contribute to the security of the mozilla browser. If you disagree with that decision, I suggest discussing this with the component owner in the newsgroups (or even in this bug if you have a good argument that has not already been said). Also, comment #5 explicitly wants _no_ dialog; rather it wants something like the cookie _menuitems_.

This wontfix is ridiculous. It seems to have been wontfixed (partially) because there is no UI design yet comment #6). The UI bug (bug 103406) has been wontfixed because this bug was wontfixed. I feel like I'm in some communistic beaurocratic nightmare. This is a feature that many have requested. Wouldn't it make more sense to "future" this bug and take the time to properly discuss its merits in a newsgroup? MStolz gives as reason that he thinks dialogues should be avoided when surfing. Fine. Then he goes on to say that it sould be done like mozilla's cooky management. Well, guess what? Look under preferences/privacy&security/cookies/ *warm me before storing a cooky*. Looky here, the user actually has the *choice* of getting a dialogue for every cooky that comes down the pike. BTW, I use this setting! Think about it, for some sites we want pop-ups (e.g., online e-mail sites) and for some sites we don't (no examples needed); and what better way for the user to decide which sites may do which things than *WHILE* he is at that site? That's all we really want: A pref to enable/diable/ask-me for various javascript events. +-Bad Ass Pref --------------------------------------+ | Open windows by themselves ( )YES ( )NO ( )ASK ME | Then, if "Ask Me" is selected, the user gets a dialogue similar to the cooky dialogue, and the USER can decide if a page can do certain things AND whether to "REMEMBER THIS DECISION". If "remember ..." is ON, then the decision is stored in a table of allowed and/or disallowed javascript events for THAT site. +- Confirm -------------------------+ | | | www.ruthlesspornsite.com wants to | | maximize the current window. | | Do you want to allow it? | | | | [ ] Remember this decision | | | | [ Yes ] [ No ] | +-----------------------------------+ It would be a pity to loose functionality because of misunderstandings. It's really no different than what we already have for cookies. Please reconsider removing the wontfix for this bug for the aforementioned reasons.

The reason to mark this WONTFIX seems to be a matter of priorities. There are no developer cycles left to deal with this. Why not future this bug, assign to nobody@mozilla.org and add the helpwanted keyword? This should make everyone happy. The issue can be revisited in the future and if some volunteer wants to implement this - great.

No... the reason this is wontfix is because the security component owner feels that implementing this will lead to a weaker security model that provides a false sense of security and is more obtrusive and annoying than the current security model. I have yet to see anyone actually address Mitchell's points.

I will try to address Mitchell's points now: Why do we make such a difference between cookies and js stuff? If a dialog is good enough for cookies, why shouldn't we use it for popups. I really cannot see why this should be a weaker security model. Mozilla is lacking in the UI support for cookies and js annoyances. Fine grained control has been implemented in the backend but unlocking all that power remains shrouded in prefs.js mystery or even lower layers. We need to come up with a clever UI for all this and it should be similar to the cookie UI since both issues are very closely related. There are essentially two ways of doing this: A cookie/js manager that allows adding and removing sites by hand and a dialog that asks on a case by case basis. Cookies implement the dialog and part of the managing UI. Why this should be unreasonable for popups is beyond me.

In my opinion, we need support for "ask me" combined with "Rembember this decision" to make Javascript something that is at all useful. I know of no other convenient way to populate site lists for permitting javascript to run. I agree that it would be pretty useless if it brought up the dialog every time, but that is what the "Remember..." checkbox is for. The idea is to make it exactly analagous to the cookie prefs. I can see no way in which the security of the browser is enhanced by not fixing this. I saw some mention (Comment #11) of getting a proper annoying content blocking UI, but it is not made clear why Mitchell doesn't like the "Ask me" concept. One possible solution to this is to implement the IE-ish zone UI from Bug 38966. It is quite possible that something like that is what Mitchell has in mind. If so, I would like to hear it from hime, and if not, I really want to know what he DOES have in mind. Right now, Javascript is useless, but necessary.

What points of Mitchell's need to be addressed here? Comment 5: "I don't get it. Am I the only one who thinks that popping up a window to ask the user if it's OK for the site to pop up a window is just nutty?" I don't see anything wrong with a dialog that comes up to ask, as long as it has a "Remember this decision" check box. In any case, I would rather have a small browser-owned dialog than a potentially large, evil-website owned dialog. More from comment 5: "Dialogs detract from the browsing experience and should be avoided, which is why I don't want an Ask Me setting." In Mitchell's opinion, this is true. In mine, it isn't. That's why "Ask me" is an OPTIONAL setting. I like vi instead of emacs, that doesn't mean I will stop other people from using whatever they want (I draw the line at Notepad, though :-) ) "I'd much rather see a good pref panel where people can set which sites should be on the no-popups list, and maybe a menu item like the Cookie Manager one: "Block Popups From This Site." A menu item that's always available is better than a confirmation dialog - a 'tell,' not an 'ask.'" I happen to agree with most of this, but I note that the cookie manager has both systems implemented. I happen to prefer the "Ask me" option for cookies, and Mitchell presumably uses the menus. This is why we have otions... "There are a lot of opinions on UI design for popup blocking. Rather than file a whole bunch of bugs, each giving a particualr opinion, I think we should work out a good overall solution, maybe in the newsgroup (n.p.m.security maybe). I'd like to amrk this WONTFIX, but let's hear some comment first." I find the whole Javascript thing to be very similar conceptually to the cookie management problem. It seems pretty reasonable to me to use the same UI for both of them. Comment 9: "Don't you think a menu item would be just as convenient as a dialog (which is just another form of pop-up window)?" I think that was adequately responded to in Comment 10. Comment 11: "Aleksey, I respectfully disagree, but I'm not a UI designer. Before we go adding features left and right, let's work out a complete design for popup-and-annoying-content blocking UI and get some real design advice." "Perfect is the enemy of good enough." Fixing this rfe solves a problem that really needs solving. The fact that there may exist a better solution shouldn't keep us from doing what we can. Responding to comment 19: "No... the reason this is wontfix is because the security component owner feels that implementing this will lead to a weaker security model that provides a false sense of security and is more obtrusive and annoying than the current security model. I have yet to see anyone actually address Mitchell's points". At no point in any of his comments did Mitchell reference security issues. His entire problem with the bug appears to be aesthetic. He doesn't like dialogs. Nothing we say here will get him to like them, so I don't see how it is possible to address his comments in any meaningful way. That doesn't mean that the bug shouldn't be reopened. It just means that he probably isn't the best person to implement the fix...

In my last comment I suggested that as mstolz dislikes the use of dialogs, he probably isn't the right person to implement a dialog based fix. In the true spirit of open source, I guess that means I should do it... The only problem is that this bug is for back-end support for the UI. What back-end support does this need? I was under the impression that full control of site-level javascript security was already available in the prefs.js. I suppose that any UI for this could really use a place to store the prefs instead of prefs.js. As far as I can tell, that is all it needs. Right now, I browse half the time with javascript turned on, and half the time with it turned off. It's worth my time to fix this. On a related note, are there any open bugs for doing site-level javascript management through menus? That would seem to make Mitchell happier, and while I prefer "Ask me" I will take what I can get. Now that I think of it, would Mitchell's preferred menu-based management need exactly the same back-end support as a popup based system? That strikes me as being a good reason to re-open this bug right there...

I just remembered Bug 38966, which is, as far as I can tell, the bug for doing the UI for this in the one, true way. That one is more general, as it is a catch-all for a lot of different pref types.

> At no point in any of his comments did Mitchell reference security issues. My apologies for not citing the bug and comment in which he has done that in the past... I could not find it (either at the time or now) in a reasonable amount of time. > It just means that he probably isn't the best person to implement the fix... It means a little more than that. Mitchell is the module owner for the security module. That means that he mozilla.org has placed that code in his trust and he needs to approve all changes to the module... Granted, "We should do this and here is the patch" is a much stronger argument than "You should do it". :) > What back-end support does this need? At the moment, a security policy can take on three values: 1) noAccess 2) allAccess 3) sameOrigin Any time a DOM object is accessed, the security manager checks the policy list for that object type and hostname. If a policy is set (if not, sameOrigin is assumed), then a check is made to see whether the policy allows the access. The back end changes (in nsScriptSecurityManager.cpp, most likely) would be: 1) Adding support for a new policy value ("askUser" ?). This includes properly handling that value of the pref and storing it in the security manager data structures in a useful way. 2) If this policy value is encountered, checking a pref for that site to see whether the user has made a decision once already. If not, we fall through to the UI part.

Here's my solution to all this: There are pop-ups that don't show menus and there are pages (also pop-ups) that while not showing may not allow the user to use a context menu (an advanced keyboard button for a context menu is there, but not everywhere). If the case is that the menu is missing or there's a JavaScript blocking to use a context menu within the page, then the "Ask Me" option should fall in. Another dreaded thing is that some pop-ups appear too quickly (another after another after another) to actually have time to tell not to make pop-ups in the first pop-up making window. And for those who don't want the "Ask Me" option, it should be optional, as in cookies. As for the feature itself, the "Ask Me" option should be switched on by default, but having an option of being disabled: [JavaScript event warning]___________________________________________________[X] The site nastypopupmakingsite.com wants to create a pop-up window. Would you like to disable pop-ups for this site? [ Yes ] [ No ] [X] Remember this decision [ ] Don't show this prompt (warning) in the future._____________________________

Correction... And there are pop-up windows that while not showing the menu may not allow the user to use a context menu (an advanced keyboard button for a context menu is there though, but not everywhere).