Talk:Bindings: Difference between revisions
From MozillaZine Knowledge Base
Jump to navigationJump to search
(userChrome.xml binding overrides may no longer be working with omni.jar) |
(XPI file is no longer unpacked to extensions/ in Gecko 2.0) |
||
| Line 1: | Line 1: | ||
It appears that the User Chrome extension may no longer work after the switch to omni.jar with Gecko 2.0 [http://forums.mozillazine.org/viewtopic.php?p=10942013#p10942013], the trick with leaving the "extensions/''name''" folder to get into the "chrome" folder of the profile using the "../../chrome" in the manifest file seems to ignore the ".." parts. Can someone verify that? --[[User:Rsx11m|Rsx11m]] 13:49, 24 June 2011 (UTC) | It appears that the User Chrome extension may no longer work after the switch to omni.jar with Gecko 2.0 [http://forums.mozillazine.org/viewtopic.php?p=10942013#p10942013], the trick with leaving the "extensions/''name''" folder to get into the "chrome" folder of the profile using the "../../chrome" in the manifest file seems to ignore the ".." parts. Can someone verify that? --[[User:Rsx11m|Rsx11m]] 13:49, 24 June 2011 (UTC) | ||
: This may be actually more related to the fact that extensions are no longer unpacked into the profile but rather just the XPI file copied: "Starting in Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1), XPI files are no longer unpacked when extensions are installed. Instead, the XPI itself is placed in the extensions directory, and files are loaded directly out of the package." [https://developer.mozilla.org/en/XPI] Thus, if the extension cannot leave the scope of the extension, ".." doesn't have any meaning as its no longer referring to a folder structure and apparently is just ignored. Packing "chrome/userChrome.xml" as such into the chrome.xpi file resolves the issue, but defies the purpose of having an extension-independent userChrome.xml file to start with... --[[User:Rsx11m|Rsx11m]] 15:02, 24 June 2011 (UTC) | |||
Revision as of 15:02, 24 June 2011
It appears that the User Chrome extension may no longer work after the switch to omni.jar with Gecko 2.0 [1], the trick with leaving the "extensions/name" folder to get into the "chrome" folder of the profile using the "../../chrome" in the manifest file seems to ignore the ".." parts. Can someone verify that? --Rsx11m 13:49, 24 June 2011 (UTC)
- This may be actually more related to the fact that extensions are no longer unpacked into the profile but rather just the XPI file copied: "Starting in Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1), XPI files are no longer unpacked when extensions are installed. Instead, the XPI itself is placed in the extensions directory, and files are loaded directly out of the package." [2] Thus, if the extension cannot leave the scope of the extension, ".." doesn't have any meaning as its no longer referring to a folder structure and apparently is just ignored. Packing "chrome/userChrome.xml" as such into the chrome.xpi file resolves the issue, but defies the purpose of having an extension-independent userChrome.xml file to start with... --Rsx11m 15:02, 24 June 2011 (UTC)
