Hi Ehsan,
Before we created the loadInfo object, the use of TYPE_OTHER in Gecko
was close to zero. Now the use of nsIContentPolicy::TYPE_OTHER is
mostly used for internal loads, but it would be good to change that to
TYPE_INTERNAL and use TYPE_OTHER sparsely or change it to something more
specific.
It would be nice if Content Policy used bit maps instead. We could set
a bit for TYPE_SUBDOCUMENT. And then set a different bit for
meta-refresh or not. Then we wouldn't need to do any mappings before
calling content policies. However, I don't think we can make this
change right now without breaking addons. Probably have to wait until a
Content Policy API revamp.
Also, favicon maps to TYPE_IMAGE here
https://dxr.mozilla.org/mozilla-central/source/dom/fetch/InternalRequest.h#42.
Thanks and good luck!
~Tanvi
On 4/6/15 10:57 AM, Ehsan Akhgari wrote:
On 2015-04-06 1:38 PM, Boris Zbarsky wrote:
On 4/6/15 1:21 PM, Ehsan Akhgari wrote:
Based on this many-to-many mapping
Yeah, that fact that RequestContext stuff is both more _and_ less
fine-grained than nsIContentPolicy is a PITA.
So we could still consider doing something like this:
1) Extend the set of nsIContentPolicy types such that there is a
many-to-one mapping from them to both the current nsIContentPolicy types
and the RequestContext types. So in particular, we'd have "toplevel
meta refresh", "frame meta refresh", "iframe meta refresh" as
nsIContentPolicy types.
2) Just pass in an nsIContentPolicy type.
3) Do the many-to-one mapping to derive the RequestContext type.
4) Do the many-to-one mapping to the current set of nsIContentPolicy
types before calling into nsIContentPolicy implementations.
This way all of "normal frame load", "iframe meta refresh", "normal
frame load", "iframe meta refresh" will map to TYPE_SUBDOCUMENT as far
as current API consumers are concerned.
The big drawback here is that any time we have this many-to-many mapping
we get a combinatorial explosion of nsIContentPolicy types to express
it... I'm OK with that if we don't expect it to happen much, I guess.
For docshell loads, I think this proposal means we'll need to add a
matrix of content policy types that can express all possible
combinations here (for example,
TYPE_SUBDOCUMENT_IN_IFRAME_WITH_METAREFRESH and
TYPE_SUBDOCUMENT_IN_FRAME_WITHOUT_METAREFRESH and so on). For some
other ones such as video, audio and track values all being treated as
TYPE_MEDIA we'd just add
TYPE_MEDIA_AUDIO/TYPE_MEDIA_VIDEO/TYPE_MEDIA_TRACK and map them all to
TYPE_MEDIA before invoking the nsIContentPolicy implementations. But
we would be unable to accept TYPE_MEDIA when creating a new channel
for example since we won't be able to decipher what RequestContext to
use for such a load, therefore some of the API surface changes in the
current approach will be preserved with the new one but with different
error conditions (breaking add-ons etc in different ways.)
Another implication of this suggestion would be that we'd start having
two different classes of content policy types, "real" ones (the ones
that nsIContentPolicy implementations need to deal with) and "shim"
ones (the ones such as TYPE_SUBDOCUMENT_IN_IFRAME_WITH_METAREFRESH)
that should only be used by code creating channels. Perhaps we can
clarify these two different classes with documentation.
Based on the above, just passing the content policy type and extending
it to encode all of the possible ("real" type, RequestContext)
mappings doesn't necessarily seem better to me than passing these two
values separately.
Jonas, what do you think?
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
