While I was testing my patches from bug1520088, I found that nsContentUtils::IsExactSitePermAllow would return incorrect result even if the principle doesn't have that permission type.

For example, calling nsContentUtils::IsExactSitePermAllow(aPricinple, "wtf") would return true. That function returned true from [1].

My usage scenario is in AutoplayPolicy, I would use top level document's principle to check whether sites have autoplay-media permission or not. I don't want it return true when site doesn't have that permission.

[1] https://searchfox.org/mozilla-central/rev/c21d6620d384dfb13ede6054015da05a6353b899/extensions/cookie/nsPermissionManager.cpp#2310-2313

[2] https://searchfox.org/mozilla-central/rev/bee8cf15c901b9f4b0c074c9977da4bbebc506e3/dom/media/AutoplayPolicy.cpp#94-99

Hi, Smaug,
Could you help me take a look for this bug? or help me direct this NI to person who can help.
Thank you!

FYI, I was testing this site [1], and then I found IsExactSitePermAllow(aPricinple, "autoplay-media") would return true after I got the screen permission.

[1] https://www.webrtc-experiment.com/screen-sharing/#21212466423507326

Are you passing wrong principal?
https://searchfox.org/mozilla-central/rev/c21d6620d384dfb13ede6054015da05a6353b899/extensions/cookie/nsPermissionManager.cpp#2310-2313 makes very much sense, since it is dealing system principal.

After some investigation, the autoplay checking for playing screen sharing happened on the chrome process, so we actually passed the system pricinple to the permission manager, which means nsContentUtils::IsExactSitePermAllow() is good without problem.

So now I will investigate why this happen on the chrome process, instead of child process, because it seems to me that the sharing content is the part of child process.

This is a low priority bug, won't cause any bug, I just curious about some unexpected behaviors.