from content process I can write to a log file with MozillaFileLogger.js

RESOLVED WONTFIX

Status

()

Core
IPC
--
blocker
RESOLVED WONTFIX
8 years ago
5 years ago

People

(Reporter: jmaher, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Reporter)

Description

8 years ago
in my work to get mochitest + e10s landed, I have moved the file logging to run inside of messageManager.loadFrameScript() calls.  This has been working until this past weekend when I updated my code.

I found 2 issues:
1) I could not access MozillaFileLogger.js from my loadFrameScript() space
2) from the content process I could do file logging

http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/MozillaFileLogger.js

This seems fundamentally broken.  This is blocking as I cannot proceed with my mochitest patch which is required next week.

Updated

8 years ago
blocking2.0: --- → final+
tracking-fennec: --- → ?

Comment 1

8 years ago
should netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect"); even work in the frame script?
(Reporter)

Comment 2

8 years ago
it is working well for getPref, but errors out on setPref.  That is how I detect from a content process script that I am running in e10s or non IPC mode.
(Reporter)

Comment 3

8 years ago
ok, I figured out the reason why I am writing to files from content.

I have this preference that gets set in the mochitest profile creation:
user_pref("signed.applets.codebase_principal_support", true);

I am confused as why we can set a pref and ignore the basic rules that are set forth with IPC.  Can we get a better understanding of this?  Some concerns I have are that we could fail tests or allow other tests to pass as a result of this.  If we can outline which services we have access to and what they are allowed to do with this preference set, I would feel comfortable landing this mochitest patch.

Comment 4

8 years ago
what do we have to do here?  Joel, is this wfm?
(Reporter)

Comment 5

8 years ago
not sure why this is a wfm, it is 100% broken.  There should be no way setting a preference would allow for elevated privileges from content to chrome.  If this is by design, can I get a list of all services and methods that will work with this preference set.

Comment 6

8 years ago
We're trying to remove support for .enablePrivilege by default, but I'm not sure that this bug needs to be around to track it. Preferences are reflected into the content process, and at that point content script can use it to get chrome access in the content process, just like it could in the chrome process. Nothing really has changed in that regard yet.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 7

8 years ago
I am fine with a wontfix, but I want to know what else works if I set preferences in my profile?

ignoring messageManager for logging would have saved a lot of time.  When we start fixing all the tests that use elevated privileges it would be nice to know what will work by changing a preference.

As a note, window.focus() and closing the browser don't seem to work with this preference.
(Assignee)

Updated

5 years ago
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.