This bug has been spun off from bug 191839. A good way needs to exist for vetoers participating in nsIContentPolicy to prompt the user if necessary to make their decision (image blocking used to do this, and cookie wants to). The problems with this prompting are as follows: 1) it's not currently possible for prompting to be prevented if a vetoer later in the list revokes the request 2) with more than one prompting vetoer in the chain, user experience goes down the drain Solutions that solves problem 1 but not problem 2 are: A) Add a readonly attribute to nsIContentPolicy that indicates if a given vetoer can ever possibly need to prompt, and keep them separate from the non-prompters (to be called after all others). This doesn't help when prompting is dependent on the specific data. B) Make ShouldLoad/ShouldProcess return a tri-state value: Accept|Reject|Prompt and insist that prompting happen in an auxiliary method, PromptToLoad/PromptToProcess (taking the same parameters and returning only Accept|Reject). This would be a feasible solution if not for problem 2. My preferred solution, and the reason I spun it out into this bug, is as follows: ShouldLoad/ShouldProcess would return a tri-state (Accept|Reject|Prompt) and provide an nsIFoo out-parameter on Prompt. The nature of what nsIFoo should be is what I want to discuss in this bug. I need to review (and would appreciate others' experiences with) existing solutions to this problem in other products before deciding on my own solution. I would need some sort of dialog/container which could hold one or more nsIFoos and render them as needed (this part needs to be extensible because different vetoers would need to provide the user with different information). My experience tells me I want something similar to Java's JPanel, where it can display itself as needed and I can toss some extra methods on to query the final decision (Accept|Reject), but not quite like JPanel--as I will explain. Since embedding customers will want to use this interface, I don't want to make prompting impossible for them by depending on some mozilla widget. I have a couple of ideas for solving this: 1) some non-UI-assuming interface that abstracts out to the lowest common denominator so that some other class could turn it into a UI (for mozilla), or an embedder-provided class can use it as necessary. This requires more thought, but I wanted to get it out into a bug to hear other comments about it while I'm thinking about it. 2) nsIInterfaceRequestor - I haven't thought this out all the way; I'd be interested in ideas for how to accomplish this with InterfaceRequestor Since I expect nsIContentPolicy to remain unfrozen until the 1.5 timeframe, I'd like to get this worked into nsIContentPolicy (instead of spinning off nsIContentPolicy2 or some such nonsense). If nsIContentPolicy can't wait for the complete solution, I can implement solution B above (and probably push the proper solution into nsIContentPolicy2). I'm CCing the owner of Embedding API because this will affect embedders.

the prompt asking for allowing images was removed, because it caused crashes. See bug 146513. Re-introducing a way of showing prompt from ContentPolicy will need bug 191839 to be fixed first. (Or at least the backend work for it.) About vetoing: When one of the implementations of ContentPolicy will veto the load of something, the other impls won't be called anymore, as it doesn't matter anymore what they say. So they won't prompt either, so there is no problem in that. There is a problem in having tons of prompts for one page, as was the case with prompting for images.

> the prompt asking for allowing images was removed, because it caused crashes. > See bug 146513. Re-introducing a way of showing prompt from ContentPolicy will > need bug 191839 to be fixed first. (Or at least the backend work for it.) I spun this bug off the ContentPolicy API bug because, as I said above, it is (potentially) a big enough issue on its own. THIS bug is the one that will deal with how to show a prompt from content policy (see the title, and notice the blocking relationship with the original API bug). > About vetoing: When one of the implementations of ContentPolicy will veto the > load of something, the other impls won't be called anymore, as it doesn't > matter anymore what they say. So they won't prompt either, so there is no > problem in that. There is a problem in having tons of prompts for one page, > as was the case with prompting for images. You miss my point: if there are 3 vetoers in the chain, with A=accept, B=prompt, C=reject, then there was no point to prompt in B because C wouldn't have allowed it either way. That much is a UE bug (especially if it's a cookie and the user thinks he/she accepted it by pressing OK but some later vetoer rejected it). Let me also clarify some terminology: by vetoer, I mean any class that implements nsIContentPolicy and has registered itself in the content-policy category (having nothing to do with what they return from shouldFoo). If this is too confusing, I can switch to something else, like participant; just as long as we can use a term consistently =). To reiterate, this bug is to find a way to make bug 146513 possible--but not just that bug, but to address the general desire to prompt from a content policy vetoer.

Sorry, adam; I misread the component description I copied your email from; this concerns dougt more than you.

-> defaults, as I can't give time to this in the near future.