Closed
Bug 739078
Opened 12 years ago
Closed 5 years ago
Extension that calls loadAndRegisterSheet doesn't work correctly in e10s Fennec
Categories
(Firefox for Android Graveyard :: Extension Compatibility, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: wgianopoulos, Unassigned)
References
Details
Attachments
(3 files, 1 obsolete file)
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.
Reporter | ||
Comment 1•12 years ago
|
||
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•12 years ago
|
||
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
Component: General → Extension Compatibility
QA Contact: general → extension-compatibility
Summary: bootstrapped extensions don't seem to work in Android XUL builds → Extension that calls loadAndRegisterSheet doesn't work correctly in e10s Fennec
Comment 3•12 years ago
|
||
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•12 years ago
|
||
I didn't think extension manifests got loaded into content processes... but even if they do, how would this work for a restartless extension?
Reporter | ||
Comment 5•12 years ago
|
||
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.
Reporter | ||
Comment 6•12 years ago
|
||
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•12 years ago
|
||
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).
Reporter | ||
Comment 8•12 years ago
|
||
(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.
Reporter | ||
Comment 9•12 years ago
|
||
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•12 years ago
|
||
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(); }
Reporter | ||
Comment 11•12 years ago
|
||
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.
Reporter | ||
Comment 12•12 years ago
|
||
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.
Reporter | ||
Comment 13•12 years ago
|
||
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.
Attachment #610121 -
Attachment is obsolete: true
Reporter | ||
Comment 14•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
This bug seems to be resolved.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 17•12 years ago
|
||
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•12 years ago
|
||
We can reopen and handle it here.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 19•12 years ago
|
||
(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•12 years ago
|
||
Comment 21•12 years ago
|
||
(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•12 years ago
|
||
(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.
Status: REOPENED → NEW
Depends on: 609602
Updated•10 years ago
|
tracking-e10s:
--- → +
Comment 24•5 years ago
|
||
Closing all opened bug in a graveyard component
Status: NEW → RESOLVED
Closed: 12 years ago → 5 years ago
tracking-e10s:
- → ---
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•