820712 - Make sure necko supports OOP but non-app browser elements: {NO_APP, isbrowser=1}

Status: NEW

(Core :: Networking, defect, P5)

Description

[Jason Duell]

We're not using this configuration in production IIUC but we might at some point, and we have tests that rely on it (that we're disabling security checks on for now: see bug 782542 comment 46),

Should be just a matter of making sure that we treat (appId=0, isbrowser=true) separately from (appId=0, inBrowser=false).  Once we're sure of that we can revert the patch in bug 782542 that turns off security checks for the existing OOP browser tests, and allow this config to pass security checks in NeckoParent.cpp

Comment 1

[Jason Duell]

Attachment: patch to reverse-apply to re-enable security checks

this patch has all the changes we did to disable security for mochitests in bug 782542.  Once we're sure the OOP non-app browser element is handled correctly we should allow them to pass sec tests in NeckoParent.cpp. and reverse apply this patch.

Comment 2

[Jason Duell]

Bent:

So we've got a slew of mochitests that are overriding network.disable.ipc.security for this reason.  

  http://mxr.mozilla.org/mozilla-central/search?string=network.disable.ipc.security

Is OOP but non-app browser elements a config that we need to support at this point, or should it remain something tests needs to manually workaround?

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Jonas knows this better than me...

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't care strongly about supporting {NO_APP, isbrowser=1} to be honest. But I also don't mind supporting it of course.

We *do* have apps that use OOP non-app <iframe mozbrowser> elements. Though they all live inside a app <iframe mozbrowser>. This is how we run the browser app in FFOS for example.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258