TypeError: native is null #2

Madis0 · 2017-11-03T19:09:14Z

When toggling the development mode, I get a notification with the text

That didn't work ...
TypeError: native is null

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.

NiklasGollenstede · 2017-11-03T19:13:59Z

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.)

Madis0 · 2017-11-03T20:02:19Z

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?

NiklasGollenstede · 2017-11-03T20:08:45Z

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).

Madis0 · 2017-11-03T20:20:03Z

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

NiklasGollenstede · 2017-11-03T20:45:50Z

Okay. Please try this:

use the System Monitor or whatever tool you have installed to find the pid of the running Firefox process
run xargs -n 1 -0 < /proc/<pid>/environ, replacing <pid> with the pid from above
check if MOZ_CRASHREPORTER_EVENTS_DIRECTORY is in the output. If not, then that is the problem

Madis0 · 2017-11-04T09:32:27Z

Yup, that does not exist. Maybe add a path field to reStyle settings?

NiklasGollenstede · 2017-11-04T14:21:25Z

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:

The extension has a severe security vulnerability and can be controlled by the attacker
via the browser.downloads API it can place files in the downloads folder (~/Downloads by default)
it downloads stealAllYourData.xpi with arbitrary scripts as extensions/@compromisedExtensionId.xpi
it tells NativeExt that the Firefox profile dir is the downloads dir
Native ext would load and execute extensions/@compromisedExtensionId.xpi in that directory
==> The attacker who previously only controlled the extension now controls your computer

So 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.

Madis0 · 2017-11-04T15:22:49Z

Can you instruct me on how to actually do that?

I found just two tutorials for it and neither even use xargs, so I'm confused.

NiklasGollenstede · 2017-11-04T16:02:33Z

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):

only for that process instance started from the terminal: prefix your command with KEY=value directly followed by your usual command
for all processes launched from that terminal window from then on: run export KEY=value [enter] then your command(s)
for a single command launched without terminal with [Alt]+[F2] (if your distro supports that): prefix your command with env KEY=value directly followed by your usual command
permanent and system wide: add KEY=value as a new line to /etc/environment (prpably requires root), see https://stackoverflow.com/questions/13046624/how-to-permanently-export-a-variable-in-linux

Madis0 · 2017-11-04T16:33:00Z

Looks 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?

NiklasGollenstede · 2017-11-04T17:02:36Z

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.

Madis0 · 2017-11-05T09:55:49Z

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? 😁

I've discussed your @document comment in the UserChrome-Tweaks repo here, you may be interested to chime in the discussion.
Aris' CustomCSSforFx only uses /*AGENT_SHEET*/ for most UI changes, again no @-moz-document here. An userContent style worked, however.
From userstyles.org I just found this which uses @namespace, but doesn't apply for some reason. Maybe because of "advanced settings"?

NiklasGollenstede · 2017-11-05T15:28:39Z

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.orgs 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.

don't use pre-parsed styles from userstyles.org (#2), set tab title as style name if style name is a number

NiklasGollenstede · 2017-11-05T21:46:42Z

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.orgs 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.

NiklasGollenstede added a commit that referenced this issue Nov 5, 2017

reject installation of empty styles (#2),

c9e03d6

don't use pre-parsed styles from userstyles.org (#2), set tab title as style name if style name is a number

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TypeError: native is null #2

TypeError: native is null #2

Madis0 commented Nov 3, 2017

NiklasGollenstede commented Nov 3, 2017

Madis0 commented Nov 3, 2017

NiklasGollenstede commented Nov 3, 2017 •

edited

Loading

Madis0 commented Nov 3, 2017 •

edited

Loading

NiklasGollenstede commented Nov 3, 2017

Madis0 commented Nov 4, 2017

NiklasGollenstede commented Nov 4, 2017

Madis0 commented Nov 4, 2017

NiklasGollenstede commented Nov 4, 2017

Madis0 commented Nov 4, 2017 •

edited

Loading

NiklasGollenstede commented Nov 4, 2017

Madis0 commented Nov 5, 2017 •

edited

Loading

NiklasGollenstede commented Nov 5, 2017

NiklasGollenstede commented Nov 5, 2017

TypeError: native is null #2

TypeError: native is null #2

Comments

Madis0 commented Nov 3, 2017

NiklasGollenstede commented Nov 3, 2017

Madis0 commented Nov 3, 2017

NiklasGollenstede commented Nov 3, 2017 • edited Loading

Madis0 commented Nov 3, 2017 • edited Loading

NiklasGollenstede commented Nov 3, 2017

Madis0 commented Nov 4, 2017

NiklasGollenstede commented Nov 4, 2017

Madis0 commented Nov 4, 2017

NiklasGollenstede commented Nov 4, 2017

Madis0 commented Nov 4, 2017 • edited Loading

NiklasGollenstede commented Nov 4, 2017

Madis0 commented Nov 5, 2017 • edited Loading

NiklasGollenstede commented Nov 5, 2017

NiklasGollenstede commented Nov 5, 2017

NiklasGollenstede commented Nov 3, 2017 •

edited

Loading

Madis0 commented Nov 3, 2017 •

edited

Loading

Madis0 commented Nov 4, 2017 •

edited

Loading

Madis0 commented Nov 5, 2017 •

edited

Loading