Bug 853747 revealed that our remote XUL hackery in bug 844783 breaks video controls. I'm investigating.

So the issue here is a permutation of a pretty familiar problem. When XBL scopes are disabled by remote XUL, we run XBL directly in the content compartment, except in automation. In this case, that broke video controls, because the NAC gets wrapped in a SOW, and the video controls can't access it anymore due to nsContentUtils::IsCallerXBL() not returning the right thing. I'm attaching a patch. But more generally, I'm worried that our in-content XBL controls will start to subtle depend on the existence of the compartment boundary, which we won't notice until we ship a release and somebody tries to use the associated element on a XUL-whitelisted domain. Jaws, dao, and dolske - can you guys keep that in mind when doing future reviews?

This is a regression from bug 844783, so we'll want to uplift both together.

Comment on attachment 728594 [details] [diff] [review] Continue checking the XBL bit if remote XUL disables XBL scopes. v1 Please document the new methods (especially the overall setup they're meant to enforce) and the difference between the two boolean members, and r=me

Comment on attachment 728594 [details] [diff] [review] Continue checking the XBL bit if remote XUL disables XBL scopes. v1 See bug 844783 comment 53.