Observers has been work into chrome process

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

[Repeated message because previous message never came to mail list]
Hello

A couple of months ago I was working with version 40 of FireFox Nightly.
document-element-inserted and the content-policy events in the chrome
process was not displaying the loading of web pages.

Now with version 40 DE FireFox I see that in chrome the process there
are challenges related to download web content (http://*) (with e10s
enabled).


I build extension with "jpm xpi" command with "permissions":
{"private-browsing": true, "multiprocess": true} in package.json .
I don't understand why I see this behavior.

Something has changed in FireFox or I have incorrectly set up the jpm build?

[Giorgio Maone]

On Tuesday, June 23, 2015 at 2:41:35 PM UTC+2, Сергей Виноградов wrote:

> I build extension with "jpm xpi" command with "permissions":
> {"private-browsing": true, "multiprocess": true} in package.json .
> I don't understand why I see this behavior.
>
> Something has changed in FireFox or I have incorrectly set up the jpm build?

Looks like your add-on is still being served by shims. Please double check that the install.rdf file inside the XPI generated by jpm actually contains a <em:multiprocessCompatible>true</em:multiprocessCompatible> element.

If it doesn't, chance are either that you're using an outdated jpm version (unlikely), or that you've got an install.rdf file in your add-on source directory, generated before you added the "permissions" key to your package.json: if this is the case, jpm is using that verbatim, rather than generating a new one with the updated parameters. Just delete the old install.rdf file and relaunch jpm xpi: everything should be fine then.

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

in xpi file the install.rdf file content following:

<?xml version="1.0" encoding="utf-8"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<Description about="urn:mozilla:install-manifest">
<em:id>HTTPUserAg...@addons.8vs.ru</em:id>
<em:type>2</em:type>
<em:bootstrap>true</em:bootstrap>
<em:unpack>false</em:unpack>
<em:version>0.7.4-a22</em:version>
<em:name>http-useragent-cleaner</em:name>
<em:description>Increases privacy</em:description>
<em:creator>Сергей Виноградов (fdsc)</em:creator>
<em:iconURL>data/HTTPUACleaner.png</em:iconURL>
<em:homepageURL>http://fxprivacy.8vs.ru/</em:homepageURL>
<em:optionsURL>data:text/xml,&lt;placeholder/&gt;</em:optionsURL>
<em:optionsType>2</em:optionsType>

<em:multiprocessCompatible>true</em:multiprocessCompatible>

<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>38.0a1</em:minVersion>
<em:maxVersion>39.0</em:maxVersion>
</Description>
</em:targetApplication>


</Description>

</RDF>

install.rdf file in build directory not present.

I switched to jpm few days ago. How to update I didn't understand, but I
think that version is quite new. (by the way, you can't tell how is jpm
updated?)

I also see that the behavior of the extension varies with multiprocess
permission and without it.
Perhaps I should try to make a new extension and if the behavior
persists, create a defect in bugzilla.


24.06.2015 23:38, Giorgio Maone пишет:

> On Tuesday, June 23, 2015 at 2:41:35 PM UTC+2, Сергей Виноградов wrote:
>

>> I build extension with "jpm xpi" command with "permissions":
>> {"private-browsing": true, "multiprocess": true} in package.json .
>> I don't understand why I see this behavior.
>>
>> Something has changed in FireFox or I have incorrectly set up the jpm build?
>

> Looks like your add-on is still being served by shims. Please double check that the install.rdf file inside the XPI generated by jpm actually contains a <em:multiprocessCompatible>true</em:multiprocessCompatible> element.
>
> If it doesn't, chance are either that you're using an outdated jpm version (unlikely), or that you've got an install.rdf file in your add-on source directory, generated before you added the "permissions" key to your package.json: if this is the case, jpm is using that verbatim, rather than generating a new one with the updated parameters. Just delete the old install.rdf file and relaunch jpm xpi: everything should be fine then.

> _______________________________________________
> dev-tech-electrolysis mailing list
> dev-tech-e...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-electrolysis
>

[Giorgio Maone]

On Wednesday, June 24, 2015 at 10:56:03 PM UTC+2, Сергей Виноградов wrote:

> I switched to jpm few days ago. How to update I didn't understand, but I
> think that version is quite new. (by the way, you can't tell how is jpm
> updated?)
>

Here's the source repository: https://github.com/mozilla/jpm

I believe yours is up-to-date, since the multiprocessCompatible stanza was there.

> I also see that the behavior of the extension varies with multiprocess
> permission and without it.

That's expected: if you've got the permission you're free of shims, and therefore things happen in the process you expect them to. Otherwise, shims "emulate" the old single process setup through transparent (but slow) messaging and CPOWs.

> Perhaps I should try to make a new extension and if the behavior
> persists, create a defect in bugzilla.
>

On Wednesday, June 24, 2015 at 10:56:03 PM UTC+2, Сергей Виноградов wrote:

> I switched to jpm few days ago. How to update I didn't understand, but I
> think that version is quite new. (by the way, you can't tell how is jpm
> updated?)
>

Here's the source repository: https://github.com/mozilla/jpm

I believe yours is up-to-date, since the multiprocessCompatible stanza was there.

> I also see that the behavior of the extension varies with multiprocess
> permission and without it.

That's expected: if you've got the permission you're free of shims, and therefore things happen in the process you expect them to. Otherwise, shims "emulate" the old single process setup through transparent (but slow) messaging and CPOWs.

Good luck.

[Giorgio Maone]

On Wednesday, June 24, 2015 at 10:56:03 PM UTC+2, Сергей Виноградов wrote:

> Perhaps I should try to make a new extension and if the behavior
> persists, create a defect in bugzilla.
>

If you do it, please CC me too, thank you.

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

I hope I did not mess up and this is really a bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1177309



25.06.2015 0:25, Giorgio Maone пишет:

> On Wednesday, June 24, 2015 at 10:56:03 PM UTC+2, Сергей Виноградов wrote:
>
>> Perhaps I should try to make a new extension and if the behavior
>> persists, create a defect in bugzilla.
>>
>

> If you do it, please CC me too, thank you.