worse is better. I don't believe that we have to fix 191839 to have an interface today that people can use.
I'd prefer some dissenting opinion on that. If we take a leave-it-broke approach, then I'll at least document the "no prompting from shouldLoad/shouldProcess" rule. Is that enough in your opinion?
i never said leave-it-broken. can't we fix under the covers? Do the changes you need required a new interface? How far we away from getting something that works correctly?
At the very least, I need a tri-state return value and some means (such as promptXYZ callbacks) to make prompters go last (so pointless prompts are avoided). The other problem that remains without bug 191839 being fixed is the UE of multiple consecutive prompts if there is more than one promper and the user wants to accept. One (hackish, IMO) solution would be to make "ACCEPT" from a promptXYZ callback be assertive (that ACCEPT is immediate and not dependent on further prompts). I'd like to cover some use cases under those conditions to be sure it doesn't break subtly (from a UE perspective).
I am not certain I'd need a new interface to allow prompting to be delegated outside of the actual shouldXYZ call, but I am unaware of any interface we have that is general enough that we could use without making embedders pull in UI nonsense. Perhaps we could just make it an nsISupports out and sort it out later, but that strikes me as a (maybe necessary) cop-out. Alternatively is the callback method I also mentioned (which would be somewhat nasty, since the object would have to drag around some state between the shouldXYZ and promptXYZ calls).
Ugh. Here's a new wrench in this (as related to bug 191839): nsIMIMEInfo *and* nsIContent--all of my "not suck" additions--are not frozen. What does that mean as far as 191839 is concerned? Of course, as luck would have it, nsIURI is not frozen, either... (perhaps that's why this interface is still unfrozen =) Sorry about the rapid-fire commenting; I think I'm done now until I get more feedback.
nsIContent will never be frozen. So if we plan to freeze nsIContentPolicy, we better not have nsIContent in there... Something like nsIDOMNode may be more appropriate. The most important thing, in any case, is to DOCUMENT what this context param does. It can stay an nsISupports if we are really willing to clearly document what callers _should_ be passing for it (which could be interpreted as exposing the inner workings of the implementation....). Bug 191839, as originally filed, is not very labor-intensive to fix. nsIMIMEInfo is not going to be frozen without a lot of work, so I would avoid its use in nsIContentPolicy if we actually want to freeze it soonish. nsIURI is frozen -- see line 91 of nsIURI.idl.
Just realized that the nsIContent idea may have arisen as a result of bug 191839 comment 4. An nsIDOMNode would be quite sufficient for the particular purpose of handling stylesheet loading via PIs... the only question is what other contexts we could have and whether nsIDOMNode is flexible enough for all of them.
It's worth pointing out that if we're forcing content policy implementations to use unfrozen classes (whether they have to QI from nsISupports or not) the inability to accept them as parameters seems improper. What I mean is that since they will always be ignored for embedders who don't care (otherwise they'd have to use the other unfrozen classes anyway), they don't seem to cost anything (as unused, they can be forward-declared, can't they?). If my suggestion is acceptable, customers who need frozenness can ignore the optional parameters (all the nonfrozen interfaces are strictly used in optional parameters). MIMEInfo is completely optional (and somewhat infrequently used; I added it because it seemed better to leave the extra parameter open for other stuff and much better than InterfaceRequestor).
if this is going to be such a PITA, i can much more easily support an interface like this as the necko layer. the nsIContentPolicy (which has nothing to do with nsIContent) interface was intended to replace an existing interface in necko.
The nsIContent parameter was a convenience parameter to allow more detailed analysis of details of the request initiator. Necko doesn't have the kind of details to solve problems I imagined nsIContentPolicy being able to solve (like blocking embedded content based on context provided in the originating document). Whether necko regains the interface or not, I would like such a high-level content veto system as where I'm leading 191839.
Doug, perhaps it would help to explain what functionality you actually want to freeze and why? (In fact, such descriptions would be helpful as opening comments of "freeze nsIFoo" bugs in general...) I agree that it would be good to freeze a usable nsIContentPolicy interface... the only question is what constitutes "usable". Fwiw, I just looked at the file attached to bug 191839, and I fail to see why nsIMIMEInfo is being used to represent a MIME type ("string" or ACString would seem more appropriate).
I agree with bz's comment and will change that in the next upload. I had forgotten that all the originating content had of it was a string in the first place, which would violate my silent driving force of making this not a PITA to use from C++ code (which creating an InterfaceRequestor or a MIMEInfo would be). That leaves nsIContent, which we've established is unnecessarily broad I would still like to run a list of intended use cases by that to make sure everybody fits into the nsIDOMNode sieve; I suppose any stragglers could be forced to use the extra parameter for anything more general than that. Okay, so that eliminates unfrozen interface usage, which leaves only how (or whether) to facilitate user interaction (e.g., prompting) when necessary.
I would like to prevent the top level loading of certain URLs. I do not think that i need all of the functionality that the nsIContentPolicy brings in.
Is it worth it to duplicate the functionality? As far as I can tell, all of the fields are currently optional except for the target URL and content type (the int parameter). Even that could be considered technically optional in that you can just pass "OTHER" if you don't care.
I will also consider organizing the parameters (and updating the comments) in such a way as to make it painfully clear what parameters are optional.
Doug, does the nsIContentPolicy api that just landed address what you needed reasonably? I believe it's worth considering for freezing once we shake out the post-landing jitters (adding consumers, etc).
mass reassigning to nobody.
Assignee: dougt → nobody
We don't freeze interfaces anymore.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.