Last Comment Bug 739078 - Extension that calls loadAndRegisterSheet doesn't work correctly in e10s Fennec
: Extension that calls loadAndRegisterSheet doesn't work correctly in e10s Fennec
Status: NEW
:
Product: Fennec Graveyard
Classification: Graveyard
Component: Extension Compatibility (show other bugs)
: Trunk
: ARM Android
: -- major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 609602
Blocks: mathml-fonts
  Show dependency treegraph
 
Reported: 2012-03-25 10:10 PDT by Bill Gianopoulos [:WG9s]
Modified: 2014-04-14 14:19 PDT (History)
8 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Simple extension illustrating the issue (1.51 KB, application/x-xpinstall)
2012-03-25 10:18 PDT, Bill Gianopoulos [:WG9s]
no flags Details
Extension re-written for e10s (2.54 KB, application/x-xpinstall)
2012-03-28 06:58 PDT, Bill Gianopoulos [:WG9s]
no flags Details
Extension re-written for e10s - update (2.56 KB, application/x-xpinstall)
2012-03-28 07:51 PDT, Bill Gianopoulos [:WG9s]
no flags Details
non-restarless extension using the category "user-style-sheets" (983 bytes, application/x-xpinstall)
2012-03-30 14:20 PDT, Frédéric Wang (:fredw)
no flags Details

Description Bill Gianopoulos [:WG9s] 2012-03-25 10:10:38 PDT
User style sheets registered by an extension via bootstrap.js seem to have no effect on Android XUL builds.

The reason I have given this a "major" Severity is that in order to resolve bug 295193, an extension has been developed to package and include the math fonts required for proper display of MathML.  This extension does not work on Android XUL builds because of this issue.

It is especially important for this to work on mobile devices which typically do not permit users installing additional fonts without "rooting" the device.
Comment 1 Bill Gianopoulos [:WG9s] 2012-03-25 10:18:39 PDT
Created attachment 609136 [details]
Simple extension illustrating the issue

This extension illustrates the issue.  It merely adds a stylesheet that sets the body background color to pink.  It works under Linux, Windows and Android native.

It does not work on current Mozilla-central Android XUL builds.
Comment 2 Matt Brubeck (:mbrubeck) 2012-03-25 14:52:26 PDT
I don't think this is a general problem with bootstrapped add-ons.  Other bootstrapped add-ons like Phony, Show Tooltips, Full Screen, etc., work fine in XUL Fennec.

More likely this extension needs to be modified to support Electrolysis, which is enabled by default in XUL Fennec.  It looks like it currently loads the stylesheet in the chrome process, while it probably needs to load it in the content process.  For details, see https://wiki.mozilla.org/Mobile/Fennec/Extensions/Electrolysis
Comment 3 Mark Finkle (:mfinkle) (use needinfo?) 2012-03-25 17:37:18 PDT
Another note. XUL Fennec used to use loadAndRegisterSheet but when we moved to e10s (and component manifests) we switched to using "agent-style-sheets" component categories:
http://mxr.mozilla.org/mozilla-central/source/mobile/xul/components/MobileComponents.manifest#40
Comment 4 neil@parkwaycc.co.uk 2012-03-26 00:33:33 PDT
I didn't think extension manifests got loaded into content processes... but even if they do, how would this work for a restartless extension?
Comment 5 Bill Gianopoulos [:WG9s] 2012-03-26 03:50:58 PDT
I managed to get this simple extension to work this way, but as said above, I can't figure out how to do this in a restartless extension.
Comment 6 Bill Gianopoulos [:WG9s] 2012-03-26 04:22:13 PDT
Oh looks like I should have read Neil's comment more closely.  The stylesheet added by that method seems to only work on pages like about:home.  and not on content pages.
Comment 7 Matt Brubeck (:mbrubeck) 2012-03-26 09:52:30 PDT
If you want to try using loadAndRegisterSheet in the content process, you can create a separate script (let's call it "content.js") that will run in the content process, and call messageManager.loadFrameScript("content.js", true) from bootstrap.js to load that file in the content process.

To shut down the extension on uninstall/disable, the parent process can send a message to the frame script using messageManager.sendAsyncMessage, and the content script can use addMessageListener to listen for that message.

You can see https://hg.mozilla.org/users/mbrubeck_mozilla.com/biggertext/ for some example code of a small add-on that uses a content script (though this is not a restartless add-on, sorry).
Comment 8 Bill Gianopoulos [:WG9s] 2012-03-27 16:48:55 PDT
(In reply to Matt Brubeck (:mbrubeck) from comment #7)
> If you want to try using loadAndRegisterSheet in the content process, you
> can create a separate script (let's call it "content.js") that will run in
> the content process, and call messageManager.loadFrameScript("content.js",
> true) from bootstrap.js to load that file in the content process.

OK.  Either I am doing something stupid or there is a bug here.
hen I try to do the messageMager.loadFrameScript from bootstrap.js, I get an Exception saying messageManager is not defined.  However, looking through other bugs, it would appear it is supposed to be defined globally.
Comment 9 Bill Gianopoulos [:WG9s] 2012-03-27 16:51:34 PDT
Oh. I should have mentioned I am doing this from within the startup function.  I would have presumed that was the correct place to do this.
Comment 10 Wesley Johnston (:wesj) 2012-03-27 16:55:18 PDT
bootstrap.js runs in its own magic context as well. If you're doing something like:

http://starkravingfinkle.org/blog/2011/01/bootstrap-jones-adventures-in-restartless-add-ons/

you should be able to the loadIntoWindow function to something like:

function loadIntoWindow(window) {
  window.messageManager.loadFrameScript();
}
Comment 11 Bill Gianopoulos [:WG9s] 2012-03-27 19:10:03 PDT
OK. I also found this. http://starkravingfinkle.org/blog/2011/01/bootstrap-jones-adventures-in-restartless-add-ons/  I will try to work on this tomorrow.

Thanks to everyone who has helped.
Comment 12 Bill Gianopoulos [:WG9s] 2012-03-28 06:58:04 PDT
Created attachment 610121 [details]
Extension re-written for e10s

OK.  Based on all of the information posted above I managed to get this all to be a restartless extension on Desktop, Native Android and Android XUL.

The problem is that under Android XUL, the stylesheet is STILL only being applied to chrome pages.
Comment 13 Bill Gianopoulos [:WG9s] 2012-03-28 07:51:57 PDT
Created attachment 610134 [details]
Extension re-written for e10s - update

Minor changes.

1.  Remove contentaccesible flag in chrome. manifest.  I had added this in an attempt to get it to work on non-chrome pages in Android XUL, but it made no difference.

2.  I am no longer setting the "delayed load flag" as I don;t think this should be necessary because of the way it is now waiting for the onOpenWIndow event.  This avoids having to worry about cleaning these up later.

3.  The big change is it fixes an issue that occurred if you removed the extension without first disabling it.  Seems you need to have the uninstall function call the shutdown function in this case.

I posted this just in case someone later on tries to use this as a starting point for their extension.
Comment 14 Bill Gianopoulos [:WG9s] 2012-03-28 11:40:55 PDT
So, is the fact that this style sheet does not apply to chrome windows an e10s issue, or a mobile XUL build issue?
Comment 15 Matt Brubeck (:mbrubeck) 2012-03-28 12:10:27 PDT
(In reply to Bill Gianopoulos [:WG9s] from comment #14)
> So, is the fact that this style sheet does not apply to chrome windows an
> e10s issue, or a mobile XUL build issue?

I'm not sure off-hand... it might be that you would also need to call loadAndRegisterSheet in the parent process (e.g. from bootstrap.js) for it to apply to the top-level chrome window.  If that doesn't work either, it might be a XUL Fennec bug.
Comment 16 Matt Brubeck (:mbrubeck) 2012-03-28 12:10:56 PDT
This bug seems to be resolved.
Comment 17 Bill Gianopoulos [:WG9s] 2012-03-28 12:58:24 PDT
Actually the real issue is NOT that the stylesheet is only applied to chrome pages and not to content, because there are chrome pages on which it is NOT applied.  The difference seems to be it is only applied on XUL pages.

So, anyway the original issue I had is that there seems to be no way for an extension to add a stylesheet to be added to content on Android XUL still exists.  Should I just file a new bug using this same extension as the testcase?
Comment 18 Matt Brubeck (:mbrubeck) 2012-03-28 13:10:40 PDT
We can reopen and handle it here.
Comment 19 Bill Gianopoulos [:WG9s] 2012-03-30 07:56:50 PDT
(In reply to Matt Brubeck (:mbrubeck) from comment #15)

> I'm not sure off-hand... it might be that you would also need to call
> loadAndRegisterSheet in the parent process (e.g. from bootstrap.js) for it
> to apply to the top-level chrome window.  If that doesn't work either, it
> might be a XUL Fennec bug.

That did not appear to make make any difference.

I have a couple of other ideas of things to try to further define the issue, but they both involve questions.

1.  Is there anywhere on Android where a userContent.css file could be placed where it would be recognized?  If not I might try a hacky patch to have it look someplace and see what happens if I load a stylesheet that way.

2.  Is there some way to run Android XUL without e10s?  Either via a config setting or some kind of patch in the build?  It does not have to be fast, just be functional.  I just want to see if doing that results in the extension working as expected or if it still fails.
Comment 20 Frédéric Wang (:fredw) 2012-03-30 14:20:03 PDT
Created attachment 611026 [details]
non-restarless extension using the category "user-style-sheets"
Comment 21 Frédéric Wang (:fredw) 2012-03-30 14:58:13 PDT
(In reply to Frédéric Wang from comment #20)
> Created attachment 611026 [details]
> non-restarless extension using the category "user-style-sheets"

FYI, this version does not seem to work either with Android XUL build...
Comment 22 Matt Brubeck (:mbrubeck) 2012-04-02 10:02:52 PDT
(In reply to Bill Gianopoulos [:WG9s] from comment #19)
> 1.  Is there anywhere on Android where a userContent.css file could be
> placed where it would be recognized?  If not I might try a hacky patch to
> have it look someplace and see what happens if I load a stylesheet that way.

It looks like userContent.css and other ways of adding user styles are all equally broken in e10s Fennec; see bug 609602.

> 2.  Is there some way to run Android XUL without e10s?  Either via a config
> setting or some kind of patch in the build?  It does not have to be fast,
> just be functional.  I just want to see if doing that results in the
> extension working as expected or if it still fails.

You can set the pref "browser.tabs.remote" to false, to disable e10s for testing purposes.  (The pref will only affect new tabs; you'll need to close and re-open any existing tabs.)  Note that some things are broken in non-remote tabs, including zooming.
Comment 23 Chris Peterson [:cpeterson] 2014-04-14 14:19:58 PDT
We don't need to track these XUL Fennec bugs for desktop e10s.

Note You need to log in before you can comment on or make changes to this bug.