Open Madis0 opened 7 years ago
There is a good very good chance that updating to NativeExt 0.2.1 fixes that. You should not need to register reStyle again. Just restart it after the installation of NativeExt.
(Yes. I just published that release. Forgot to press "publish" before.)
Tried it out, getting the same error when development mode gets disabled and another error when it gets enabled:
Error: MOZ_CRASHREPORTER_EVENTS_DIRECTORY environment variable not set by Firefox
It is easy to speculate what this means, but how is that relevant to this extension?
NativeExt needs to find the installation of the extension on the disk. That can be very tricky. With Firefox, it relies on the MOZ_CRASHREPORTER_EVENTS_DIRECTORY
env var to point to a directory inside the profile.
I havn't encountered a situation where it is not set. That you did is quite concerning.
So what do you mean by "development mode"?
And do find your original problem, please open the browser console (Ctrl
+Shift
+J
) and give me the full stack trace of the TypeError: native is null
error (should appear at the same time the notification does).
With Firefox, it relies on the MOZ_CRASHREPORTER_EVENTS_DIRECTORY env var to point to a directory inside the profile. I havn't encountered a situation where it is not set. That you did is quite concerning.
Hmm. It may be related that I use this PPA for installation and updates. The official method of tar.gz is too much of a hassle IMO.
So what do you mean by "development mode"?
The option below UI styles.
full stack trace of the TypeError: native is null error
22:17:06.140 TypeError: native is null
Stack trace:
disable@moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/background/local/index.js:119:2
@moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/background/local/index.js:18:115
async*fire/ready<@moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/event.js:30:26
Async*fire@moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/event.js:29:44
async*onChanged/<@moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/options/index.js:296:22
onChanged@moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/options/index.js:288:23
1 index.js:100:22
reportError moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/index.js:100:22
<anonymous> moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/background/local/index.js:18:146
(Async: async)
fire/ready< moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/event.js:30:26
fire moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/event.js:29:44
onChanged/< moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/options/index.js:296:22
onChanged moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/options/index.js:288:23
And just in case it helps, a stack trace for the other one:
22:17:10.743 Error: MOZ_CRASHREPORTER_EVENTS_DIRECTORY environment variable not set by Firefox
Stack trace:
Error: MOZ_CRASHREPORTER_EVENTS_DIRECTORY environment variable not set by Firefox
at module.exports (/snapshot/native-ext/browser.js:134:11)
at ready (/snapshot/native-ext/connect.js:119:65)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7) 1 index.js:100:22
reportError moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/index.js:100:22
<anonymous> moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/background/local/index.js:18:146
fire/ready< moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/event.js:30:26
fire moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/utils/event.js:29:44
onChanged/< moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/options/index.js:296:22
onChanged moz-extension://8ef379d7-344b-4edc-833f-b32b875422c7/node_modules/web-ext-utils/options/index.js:288:23
Okay. Please try this:
xargs -n 1 -0 < /proc/<pid>/environ
, replacing <pid>
with the pid from aboveMOZ_CRASHREPORTER_EVENTS_DIRECTORY
is in the output. If not, then that is the problemYup, that does not exist. Maybe add a path field to reStyle settings?
The security concept of NativeExt is that it finds the extension installation itself. That way (unless a file in the extension calls eval()
) it can make sure that only the code shipped by the extension is executed, even if the extension is compromised. If the extension can tell NativeExt where it should be loaded from, this would be a possible scenario:
browser.downloads
API it can place files in the downloads folder (~/Downloads
by default)stealAllYourData.xpi
with arbitrary scripts as extensions/@compromisedExtensionId.xpi
extensions/@compromisedExtensionId.xpi
in that directory
==> The attacker who previously only controlled the extension now controls your computerSo having a UI option inside the extension that specifies the profile directory is not a good idea.
I'll try to find a different way to deduct the profile directory, but in the meantime, you could set the MOZ_CRASHREPORTER_EVENTS_DIRECTORY
env var to path/to/your/random.profile/crashes/events
before starting Firefox. NativeExt should inherit that.
neither even use xargs
The xargs
in xargs -n 1 -0 < /proc/<pid>/environ
only formats the content of /proc/<pid>/environ
. Otherwise, it is not related to the env vars.
Can you instruct me on how to actually do that?
It really depends on how you currently start Firefox, and if you want to set the env var globally or just for Firefox (given the long name, MOZ_CRASHREPORTER_EVENTS_DIRECTORY
shouldn't conflict with anything, so setting it permanently globally shouldn't be a problem):
KEY=value
directly followed by your usual commandexport KEY=value
[enter] then your command(s)env KEY=value
directly followed by your usual commandKEY=value
as a new line to /etc/environment
(prpably requires root), see https://stackoverflow.com/questions/13046624/how-to-permanently-export-a-variable-in-linuxLooks like that profile is so crash-free it didn't have the two folders 😁 But the other profiles I have still lack the env variable, even if the two folders are present.
Anyway, tried the first method so I wouldn't permanently mess up anything and progress - another error came up:
Error: ENOENT: no such file or directory, scandir '/home/user/dev/user-styles'
I guess it just didn't generate the folder?
It doesn'T really matter if the folders actually exist. NativeExt simply reads the env var and assumes that the root of the profile folder is two directories up. If you use different Firefox profiles, you need to launch each of them with the MOZ_CRASHREPORTER_EVENTS_DIRECTORY
to a folder that is a "grandchild" of that profile folder.
Error: ENOENT: no such file or directory, 'scandir /home/user/dev/user-styles'
I guess it just didn't generate the folder?
~/dev/user-styles
is just the default location reStyle loads your local user styles from, if the Development mode is enabled. You can either create the folder and put css files in it, change the preference on the options page or disable Development mode.
It doesn'T really matter if the folders actually exist.
You can either create the folder and put css files in it, change the preference on the options page or disable Development mode.
If it causes an error and prevents it from working, it does matter... You also contradict yourself with the second sentence. Regardless, I have created a folder now and am no longer getting errors.
Now I've seen userChrome.css and userContent.css files with
/* Do not edit this section of this file (outside the Browser Toolbox). It is managed by the reStyle extension. */ /*START:_some-uuid-here_*/
/*END:_some-uuid-here_*/
so things seem to work.
So now my only question is, do you know any valid 57+ Stylish styles to actually test? 😁
/*AGENT_SHEET*/
for most UI changes, again no @-moz-document
here. An userContent style worked, however.@namespace
, but doesn't apply for some reason. Maybe because of "advanced settings"?It doesn'T really matter if the folders actually exist.
You can either create the folder and put css files in it, change the preference on the options page or disable Development mode.
If it causes an error and prevents it from working, it does matter...
I was talking about to different folders there. The MOZ_CRASHREPORTER_EVENTS_DIRECTORY
doesn't need to exist, as far as NativeExt or reStyle are concerned.
The folder set as Development Mode
> Local folder
should exist. Since I can't generally assume that to be the case, I should probably disable Development Mode by default.
do you know any valid 57+ Stylish styles to actually test?
All the styles in my user style collection used to work with Stylish for Firefox and now work with reStyle. So should almost all styles on userstyles.org
that properly use @-moz-document
rules.
From userstyles.org I just found this which uses @namespace, but doesn't apply for some reason. Maybe because of "advanced settings"?
reStyle supports userstyle.org
s style settings, that shouldn't be the problem. I'll have a look at it.
I've discussed your @document comment in the UserChrome-Tweaks repo here, you may be interested to chime in the discussion.
Will do.
uses
/*AGENT_SHEET*/
There are three possible "origins" of CSS sheets, (user) agent, user and (website) author. WebExtensions can apply styles to websites as either user or author, and the styles in the userC*.css
files are applied as user styles.
Stylish detects the /*AGENT_SHEET*/
string and applies those styles with the origin of agent. So that comment tells stylist how to apply the style, not where.
Because there is no way for reStyle to apply agent sheets, there is nothing it can do with the presence or absence of that string in a CSS file.
From userstyles.org I just found this which uses @namespace, but doesn't apply for some reason. Maybe because of "advanced settings"?
reStyle supports
userstyle.org
s style settings, that shouldn't be the problem. I'll have a look at it.
Because they are a bit faster to parse, reStyle used to fetch the reprocessed styles for Stylish for Chrome when installing styles with options. I guess because the style in question is solely for Firefox, userstyle.org
returned an empty response.
When toggling the development mode, I get a notification with the text
Using successful installs of NativeExt 0.1.0 for Linux x64, packaged script from reStyle 0.2.1b8, Firefox 58.0a1 (2017-11-03), Ubuntu 17.10.