development: help & discussion

[myrdd]

This issue is for help and discussion of any kind of short comments or questions, regarding development of RequestPolicy (Continued). For example, post here if you've got trouble with building, running or testing RP; or post your questions about the source code.

Just for reference, this is the location of the development release: https://requestpolicy.256k.de/requestpolicy-nightly.xpi

[metadings]

Hey @myrdd, don't you want to create a "new" RequestPolicy ... ?

I do want to move about:requestpolicy?defaultpolicy to about:requestpolicy?yourpolicy, just to make the "Full Opt-In" feature more visible to the user.

I can do make these changes... So are You with me? I am asking, not to be wrong here... i just want to know if can help you, creating RequestPolicy ?

[metadings]

Actually, to get this AddOn running is really hard, compared to the noscript AddOn, there's a lot of bloat in there.

[myrdd]

If want to consolidate the defaultpolicy and yourpolicy pages, create a plan and present it in an issue. Be sure to check existing issues.

Actually, to get this AddOn running is really hard, compared to the noscript AddOn, there's a lot of bloat in there.

You do not need to use all features in the makefile. make xpi should be usually enough. I found it convenient to have make run commands.

[Atavic]

I suggest you to add some words here to explain why RP does more than uMatrix. That's because RP has its own supriscriptions, while currently uMatrix hasn't any.

[myrdd]

@LiamZ would like to help on the WebExtension transition. [https://github.com/RequestPolicyContinued/requestpolicy/issues/704#issuecomment-341583072] Great! :)

I'll have trouble understanding the existing XPCOM code, having never made an add-on myself.

No worries, there's a lot of non-xpcom code. Maybe you could simply create a WE-only module? Take a look at this issue: https://github.com/RequestPolicyContinued/requestpolicy/issues/863. Do you think you could work on that issue?

[LiamZ]

I could probably do it, yes. I'll work on it.

[myrdd]

Great, I'm looking forward! :)

[myrdd]

@LiamZ what do you think about some kind of chat conversation to improve joint effort, e.g. on IRC?

[leedoyle]

@myrdd hello! I'm perfectly aware that's not the priority, but I've come across a curious bug. The description: https://github.com/gorhill/uMatrix/issues/810 (It affects both extensions so everything applies to RPC as well). Could you give any insight on why this could be happening and possible ways of dealing with it apart from forcing mobile version?

[myrdd]

@leedoyle I cannot reproduce the described behavior in RPC. Note that RPC does not block web content by type, only by their url, so scripts are executed (if they are loaded). If you can reproduce the issue, please create a separate issue and I'll take a look.

[jrrdev]

@myrdd If you need some extra hands maybe I can give some help with the WE transition. Is there some issues I can work on ?

[myrdd]

@jrrdev great! :) Take a look at this one: #865 I'm preparing more issues.

[myrdd]

Another one: https://github.com/RequestPolicyContinued/requestpolicy/issues/866

Tell me if you're getting into trouble. :)

[jrrdev]

PR made for issues #865 and #866, I don't see any other issue related to WE transition except #863. @LiamZ are you working on it ? Or @myrdd do you have more issues related to WE transition I can help on ? :-)

[myrdd]

I'll create some more issues later today. Great you're helping! :-)

btw @jrrdev are you comfortable with TypeScript (TS)? https://www.typescriptlang.org/docs/home.html https://github.com/RequestPolicyContinued/requestpolicy/search?l=typescript At least reading TS shouldn't be a problem to you, since it's a superset of JS. I'm successively translating JS modules to TS (when it makes sense). TS helps a lot understanding and navigating through more complex code (like the request processing and request storage parts) as well as preventing hard-to-find bugs.

[jrrdev]

Well I used it a little bit when I was playing around with Angular 2, so I guess it won't be a problem reading/writing some TS (actually I find it kinda easier to read than pure JS :-))

[myrdd]

That's good! :) I will create (not today) an issue that requires some TS knowledge. I'll let you know. :)

[wilkowy]

How do I disable localized UI? After updating to 13.2 (from 13.1 I believe, well the previous one available) RPC uses my OS locale (pl) than Firefox UI. I've contributed the "pl" translation, however I'd prefer to use "en" one.

Fx 48.0.2 (I don't remember, either us version or int) general.useragent.locale = en-US intl.locale.matchOS = false

[jrrdev]

Hi, I'm not sure if it is possible by changing some settings. It's seems that some values are hard-coded depending on the package you download, maybe try to install the US version. To go deeper, this is the code snippet related to locale matching. Because you are using FF 48, it will use Services.locale.getApplicationLocale and according to [Mozilla doc](https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsILocaleService#getApplicationLocale()):

Gets the user preference for locale from the operating system. Note: This has nothing to do with the locale used for localization of the application (UI text strings and so on.). This method returns something similar to getSystemLocale. So:

• it's seems to be independent from general.useragent.locale
• maybe intl.locale.matchOS parameter will switch getApplicationLocale to package locale, but I'm not very confident with that because of what the doc says... :confused:

[wilkowy]

Flipping intl.locale.matchOS affects other addons like uBO which change locale from en to pl. RPC is not affected.

[myrdd]

moved to #890

[cheggerdev]

What are next steps towards full WE port?

[cheggerdev]

There are no more pre-release versions available at https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/beta Is this intended? Just saying.

[myrdd]

There are no more pre-release versions available at https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/beta Is this intended? Just saying.

No, this is not intended. All beta versions are marked as ”Disabled by Mozilla“!

I need to figure out how to fix this.

What are next steps towards full WE port?

I've got an overview of what to do on my PC. I think it's a good idea to publish them, to allow for comments and collaboration.

[myrdd]

There are no more pre-release versions available at https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/beta

AMO beta versions have been discontinued: https://github.com/RequestPolicyContinued/requestpolicy/issues/895

[baptx]

I just noticed in my GitHub favorites that RequestPolicy has switched from JavaScript to TypeScript (you can also see it here: https://github.com/RequestPolicyContinued), is it normal? Why not keep development simple in pure JavaScript instead of switching to TypeScript which adds another abstraction layer using a third-party framework? Also not everybody knows TypeScript and likes the idea to use a Microsoft language for an open source project.

[myrdd]

Hi @baptx. Yes, I moved away from pure JavaScript to TypeScript. I understand your objection regarding Microsoft and Open Source. IMHO it's the biggest downside of my decision of switching to TypeScript. I think Microsoft aims to increase its influence on open source ”communities“. Still, using TS isn't a big dependence. Let me show:

Technically, compared to JavaScript, TypeScript is simply the addition of type annotations. That is, instead of writing let name; you write let name: string;. The TypeScript compiler (tsc) simply removes those type annotations. So if you wanted to switch back to pure JS, you simply had to remove all those annotations. Using TS does not add a new run-time layer (but it adds a build-time layer).

not everybody knows TypeScript

That's quite easy to solve. First, you can mix JS and TS files. Second, you can use the any type anywhere, e.g. let name: any;. You can then write name = 123; without getting any error or warning.

By the way, I did not mention the advantages of using TS. The static typing allows me to detect bugs without running the application or performing tests. Additionally, when using a code editor with support for TS, it's very easy to inspect variables, functions or classes; and to navigate through the files based on objects available in multiple files.

One thing left to mention: I am using the tsc option "target": "es5" and others (see tsconfig.json). This indeed changes (maps) any es6+ code (e.g. classes) to es5 code. However, this could be done equally with Babel. (I tried to use Babel instead of the tsc es5 compiler options, but I wasn't able to fix some issues regarding the combination of tsc+babel+gulp. Still, es5 compatibility is needed only for some (older) browsers. PaleMoon 27 was based on Firefox 45.)

[baptx]

@myrdd hi, thanks for the informations. I still think that most developers prefer to use pure JavaScript which is a standard so it also has the advantage that it can run without being transcompiled (I would rather see official upgrades to the JavaScript or CSS standard than transcompiling every interpreted language for a few features that are not really necessary). Another point may be if TypeScript becomes unsupported in the future or if there is a new version of TypeScript that comes out without backward compatibility, the whole codebase would be deprecated and developers would have to rewrite everything. I also guess that it is possible that TypeScript introduces security vulnerabilities someday if something is not transcompiled correctly (it does not work the same way but it happened several times with jQuery).

[myrdd]

Let me highlight this from wikipedia:

[TypeScript] is a strict syntactical superset of JavaScript. […] As TypeScript is a superset of JavaScript, existing JavaScript programs are also valid TypeScript programs.

--

Another point may be if TypeScript becomes unsupported in the future or if there is a new version of TypeScript that comes out without backward compatibility, the whole codebase would be deprecated and developers would have to rewrite everything.

You only need to remove all those type annotations. You do not need to rewrite everything.

I also guess that it is possible that TypeScript introduces security vulnerabilities someday if something is not transcompiled correctly

That's a valid point. The compiled js code doesn't differ too much from the ts source, but I think it would be a good idea to eventually remove the tsc options for es5 transpilation I mentioned above.

transpiling […] for a few features that are not really necessary

I highly appreciate the features offered by typescript. TS makes it a lot easier not to introduce new bugs when refactoring or changing code.

[myrdd]

@shirishag75 late answer on https://github.com/RequestPolicyContinued/requestpolicy/issues/704#issuecomment-390531780

To find out the version of a XPI file, open the install.rdf inside it and take a look at the line containing right below <em:name>RequestPolicy Continued</em:name>, e.g.:

  <Description about="urn:mozilla:install-manifest">
    <em:name>RequestPolicy Continued</em:name>
    <em:version>1.0.beta14.0</em:version>

You can see that in the example the version is 1.0.beta14.0

[shirishag75]

@shirishag75 late answer on #704 (comment)

To find out the version of a XPI file, open the install.rdf inside it and take a look at the line containing right below <em:name>RequestPolicy Continued</em:name>, e.g.:

  <Description about="urn:mozilla:install-manifest">
    <em:name>RequestPolicy Continued</em:name>
    <em:version>1.0.beta14.0</em:version>

You can see that in the example the version is 1.0.beta14.0

I actually deduced that when I built the .xpi, copied the file to another directory, renamed it to a .zip extension and extracted the archive and was able to read the install.rdf. Maybe the build script could be made such a way so the versioning comes in the name of the extension itself, so instead of requestpolicy-commitid.xpi or requestpolicy.xpi it is requestpolicy-version.xpi or requestpolicy-version-commitid.xpi if need be. If need be, I can put up wishlist ticket/issue newly so that could be worked upon.

[myrdd]

@shirishag75 I consider this quite low-priority. personally, for development, I prefer to have unchanged filenames instead of unique ones. it would be easy to make it env-variable dependent, e.g. using a local Makefile.local. Feel free to request this in a new issue.

[Ryuno-Ki]

@baptx wrote in https://github.com/RequestPolicyContinued/requestpolicy/issues/826#issuecomment-416960412

I still think that most developers prefer to use pure JavaScript which is a standard so it also has the advantage that it can run without being transcompiled (I would rather see official upgrades to the JavaScript or CSS standard than transcompiling every interpreted language for a few features that are not really necessary).

I agree with you here. I had some struggle learning TypeScript (like annotating with | and so on). However, TypeScript is gaining in popularity because for some reasons, people love type annotations these days … (to me it feels like writing JavaScript as if it were Java …).

Another point may be if TypeScript becomes unsupported in the future or if there is a new version of TypeScript that comes out without backward compatibility, the whole codebase would be deprecated and developers would have to rewrite everything.

So my middle-ground is using Flow with flow-jsdoc, since it builds on top of JSDoc strings. So I can use them for documentation and type checking without sacrificing executability of the code as-is.

I also guess that it is possible that TypeScript introduces security vulnerabilities someday if something is not transcompiled correctly (it does not work the same way but it happened several times with jQuery).

Thing is, since some time, people throw tooling at their code to „optimise” it (I'm looking at you, webpack). Personally I compare the output with my source code. Tools like rollup are doing a pretty good job at keeping the output small.

[myrdd]

thanks for your comment @Ryuno-Ki, that's helpful. I'm going to keep track of Flow. Personally, I really like the TS syntax, especially when comparing to JSDoc style comments; but of course that's purely subjective. One good point about JSDoc is that it's recognized by many more tools.

FTR, this is the current tsconfig (relevant part):

https://github.com/RequestPolicyContinued/requestpolicy/blob/30736666c73010ef8589bb94d7bad7006affdde9/tsconfig.json#L5-L9