Re: E10S problem with http request and nsIContentPolicy handling

[Виноградов Сергей]

I got the answers to 1 and 2 questions.

Anyone can answer 3 and 4?




16.04.2015, 22:00, "Виноградов Сергей" <fd...@yandex.ru>:
> I tried FireFox Nightly with E10S. However I have several problems:
>
> 1. nsIContentPolicy is now called only for internal downloads (chrome:// and resource://). How to register it? now registration underway in chrome code via categoryManager 'content-policy' (similary behavior with 'simple-content-policy')
>
> 2. Similarly, document-element-inserted event is called only for internal downloads.
>
> 3.  In the  'http-on-opening-request' event I do not see way to send synchronous messages. MessageManager does not support the synchronous interface. However, I need
>
> 4. On the basis of the document loaded in the tab, to make certain decisions. I am now get field browser._documentURI.spec. however, this is a private field. I understand that it should not be used.
> Without synchronous messages cannot determine the address of the loaded document. (tab URI is not suitable)
>
> Who either knows how to solve it?
> _______________________________________________
> dev-tech-electrolysis mailing list
> dev-tech-e...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-electrolysis

[Giorgio Maone]

On Thursday, April 23, 2015 at 10:14:15 PM UTC+2, Виноградов Сергей wrote:
> I got the answers to 1 and 2 questions.

Just for the record, I assume you've been told "useful" nsIContentPolicy implementations and 'document-element-inserted' observers must live inside frame scripts.

> Anyone can answer 3 and 4?

A better understanding of what you're trying to accomplish would really help here.
1. Would suspending the channel until the asynchronous back and forth messaging is done be acceptable?
2. Otherwise, would the referrer URL be a good replacement your checks ( see http://lxr.mozilla.org/mozilla-central/source/netwerk/base/nsNetUtil.h#1204 for retrieval hints)
3. Is your add-on's source code of available somewhere to take a look and figure out what it's supposed to do?



>
>
> 16.04.2015, 22:00, "Виноградов Сергей":

[Виноградов Сергей]

Hello

Yes, I understand that nsIContentPolicy implementations and 'document-element-inserted' observers must live inside frame scripts.

However, I see that frame script execute for each tab (in global MM). But while the register is probably for window.
I see now that I can not properly remove event handlers. Could you explain where it is better to remove? Or give a link to a specific place documentation.

var mm = Cc["@mozilla.org/globalmessagemanager;1"].getService(Ci.nsIMessageListenerManager);
mm.loadFrameScript(require('sdk/self').data.url("mainjs/contentWorker.js"), true);

This is done in order to get to all the tabs.
Don't know, maybe there's another way, where will be more convenient to register handlers?



I think I understand that any request before the 'http-on-opening-request' passes nsIContentPolicy.
Probably, I can just mark browser object from handler nsIContentPolicy (by sync message) that it browser kept separate fields with the appropriate data handler for 'http-on-opening-request'.
Perhaps then this question can be removed. Thanks for the help


(P.S. My addon https://addons.mozilla.org/firefox/addon/http-useragent-cleaner/ )


08.05.2015, 00:42, "Giorgio Maone" <gio...@maone.net>:
>> ...

> Just for the record, I assume you've been told "useful" nsIContentPolicy implementations and 'document-element-inserted' observers must live inside frame scripts.

>> ...

>
> A better understanding of what you're trying to accomplish would really help here.
> 1. Would suspending the channel until the asynchronous back and forth messaging is done be acceptable?
> 2. Otherwise, would the referrer URL be a good replacement your checks ( see http://lxr.mozilla.org/mozilla-central/source/netwerk/base/nsNetUtil.h#1204 for retrieval hints)
> 3. Is your add-on's source code of available somewhere to take a look and figure out what it's supposed to do?

>>  16.04.2015, 22:00, "Виноградов Сергей":

[Giorgio Maone]

On 09/05/2015 22:35, Виноградов Сергей wrote:
> However, I see that frame script execute for each tab (in global MM). But while the register is probably for window.
> I see now that I can not properly remove event handlers. Could you explain where it is better to remove? Or give a link to a specific place documentation.
>
> var mm = Cc["@mozilla.org/globalmessagemanager;1"].getService(Ci.nsIMessageListenerManager);
> mm.loadFrameScript(require('sdk/self').data.url("mainjs/contentWorker.js"), true);
>
> This is done in order to get to all the tabs.
> Don't know, maybe there's another way, where will be more convenient to register handlers?

As the name suggests, the global message manager operates on each
<browser>, no matter which window hosts it.
Therefore, in a SDK add-on, the most reasonable time to register a
global listener would be at add-on startup, i.e. exports.main(). You
want to remove it on add-on shutdown, i.e. in exports.onUnload(). Of
course you can make your listener(s) code live in a separate module and
call its own initialization and disposal routines from main() and
onUnload().
-- G

[Виноградов Сергей]

Grigorio

I incorrectly explained. I mean registration with code

loadExtension()
{

var mm = Cc["@mozilla.org/globalmessagemanager;1"].getService(Ci.nsIMessageListenerManager);
mm.loadFrameScript(require('sdk/self').data.url("mainjs/contentWorker.js"), true);
}

inFrameScriptSetO()
{
var registrar = Cm.QueryInterface(Ci.nsIComponentRegistrar);
registrar.registerFactory(HTTPUACleaner.observer._classID, HTTPUACleaner.observer._classDescription, HTTPUACleaner.observer._contractID, HTTPUACleaner.observer);

var catMan = Cc["@mozilla.org/categorymanager;1"].getService(Ci.nsICategoryManager);
catMan.addCategoryEntry("content-policy", HTTPUACleaner.observer._contractID, HTTPUACleaner.observer._contractID, false, true);
}

inFrameScriptRemoveO()
{
var catMan = Cc["@mozilla.org/categorymanager;1"].getService(Ci.nsICategoryManager);
catMan.deleteCategoryEntry("content-policy", HTTPUACleaner.observer._contractID, false);

registrar.unregisterFactory(HTTPUACleaner.observer._classID, HTTPUACleaner.observer);
}


loadFrameScript function will execute the "mainjs/contentWorker.js" script in each tab. But inFrameScriptSetO must be execute only one per Frame Process, but not per one tab.
And unregisterFactory must be call only one time per Frame Process. It cannot be linked to the closing of the tab.

Perhaps it can be called from a sdk/windows.close event, but where to send an asynchronous message when closing the window?
And will this code actually executed?

Frankly, I don't really understand where the boundaries are frame script (pre window or for the entire browser) and what happens when the frame script process has be terminating.


10.05.2015, 00:18, "Giorgio Maone" <gio...@maone.net>:

[Giorgio Maone]

On 10/05/2015 00:21, Виноградов Сергей wrote:
> loadFrameScript function will execute the "mainjs/contentWorker.js" script in each tab. But inFrameScriptSetO must be execute only one per Frame Process, but not per one tab.
> And unregisterFactory must be call only one time per Frame Process. It cannot be linked to the closing of the tab.

In order to execute something just once per child process, you may let
your frame script import/require a module containing your "run-once"
code at the top level. This will ensure it will run just once, even if
you import it from multiple frames.
When your add-on is unloaded, just broadcast a message which tells your
frame script to call a cleanup function exported by the aforementioned
module, taking care that calling this function multiple times doesn't
cause any ill effect (by setting an "disposed" boolean flag, for
instance), because that's what will generally happen.

[Bill McCloskey]

Starting in Firefox 38, we have the ability to load "process" scripts.
These are similar to frame scripts, but they run once in each process. They
landed in bug 1133594.

Here is some example code:

-- addon.js --
let ppmm = Cc["@mozilla.org/parentprocessmessagemanager;1
"].getService(Ci.nsIProcessScriptLoader);
ppmm.loadProcessScript("chrome://whatever/process-script.js", true);
ppmm.addMessageListener("Hello", function(msg) { ... });

-- process-script.js --
if (Services.appinfo.processType == Services.appinfo.PROCESS_TYPE_CONTENT) {
dump("Welcome to the process script in a content process");
} else {
dump("Welcome to the process script in the main process");
}
sendAsyncMessage("Hello"); // Message is sent using
childprocessmessagemanager

The dump statement will run once in each running content process as well as
in the main process. You can use Components from a process script. When
your add-on is shut down, you should remove process scripts via
ppm.removeDelayedProcessScript("chrome://whatever/process-script.js"). This
will stop the process script from being loaded into new content processes.
You'll also need to send a message to the existing scripts telling them to
unload.

Unfortunately we don't have any documentation on these yet.

Before Firefox 38 (which will be released very soon), you can Cu.import a
JSM from a frame script, as Giorgio described. The JSM will run once per
content process.

-Bill