Closed Bug 208801 Opened 21 years ago Closed 14 years ago

Freeze nsIContentPolicy

Categories

(Core Graveyard :: Embedding: APIs, defect)

Product:
Core Graveyard
Component:
Embedding: APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: dougt, Unassigned)

References

(
URL
)

Details

 
Adding dependency on bug 191839 ("Content Policy API sucks rocks")
Depends on: 191839
OS: Windows XP → All
Hardware: PC → All
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
QA Contact: carosendahl → apis
We don't freeze interfaces anymore.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.