a web browser extension that gives you control over cross-site requests. Available for XUL/XPCOM-based browsers.
Home Page: https://github.com/RequestPolicyContinued/requestpolicy/wiki
License: Other
RequestPolicy is a browser extension for Firefox(*) and SeaMonkey that gives you control over cross-site requests. It does this through user-defined whitelists and blacklists. Users can also subscribe to policies (whitelists and blacklists) maintained by others.
Have a look at our wiki, especially the Quick Start guide and the FAQ.
(*) Firefox 57+ is not yet supported
Almost all code is licensed under GPL v3 or later, some files are licensed under MPL 2.0. See LICENSE.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#36
imported trac ticket
created: 2009-09-15 08:57:55
reporter: justin
Aerik Knapp-Loomis writes:
Currently there's a bug where when you open a new tab and contains a redirect, the tab that you clicked over from will have somehow interacted with RP as if you allowed a request from the second tab.
For example, every time I'm on google reader and I ctrl+click on a link to a new tab that's located at feedproxy.google.com, which is always a redirect, the google reader tab will show that I've allowed a request from feedproxy.google.com.
This issue has been known and reported a few times before and it's time to make a ticket for it. However, I'm not sure how to fix it. There are fundamental issues with lacking information that Firefox makes available to us when we block or allow requests. It may be the case that solving this involves using a lot more DOM inspection for generating the menu, which is something we'd like to avoid for simplicity and speed reasons.
I need to spend some time on this, though, to see if there's an easier fix I'm not thinking of that won't involve complicating !RequestPolicy a lot just to deal with this issue.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#24
imported trac ticket
created: 2009-07-25 13:38:58
reporter: justin
On !SeaMonkey 2.0b2pre, using "open link in new tab" fails when trying to open a cross-site link. What you get is a blank tab and the following message which looks like the browser reacting to !ShouldLoad returning false for the url it's trying to display in the new tab:
{{{
Error: uncaught exception: [Exception... "Component returned
failure code: 0x805e000a [nsIWebNavigation.loadURI]" nsresult:
"0x805e000a ()" location: "JS frame :: chrome://global/content/bindings/browser.xml
:: loadURIWithFlags :: line 186" data: no]
}}}
The fundamental problem is that our registerLinkClicked() function is not getting called. There is some chance this is the result of the crappy workaround for !TabMixPlus in our _wrapAddTab() function in overlay.js.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#17
imported trac ticket
created: 2009-06-21 17:54:26
reporter: justin
When using the Sage-Too extension, redirected RSS feeds within Sage-Too are blocked.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#18
imported trac ticket
created: 2009-06-21 17:59:42
reporter: justin
Cross-site redirected feeds are not only blocked but may not even be retained by !NewsFox if it cannot retrieve them. Additionally, some content (e.g. images) of feeds is blocked because the requests have the origin of "about:blank".
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#38
imported trac ticket
created: 2009-09-16 12:54:51
reporter: aja
0.5.8 breaks opening of new tabs (via context menu, or otherwise) with latest trunk nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090915 Minefield/3.7a1pre ID:20090915053258
I get the following in Console2:
Error: '[JavaScript Error: "uri is null" {file: "file:///C:/Documents%20and%20Settings/Aja/Application%20Data/Mozilla/Firefox/Profiles/y5aydfee.central/extensions/[email protected]/modules/DomainUtil.jsm" line: 186}]' when calling method: [nsIRequestPolicy::registerLinkClicked] = NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS Source file: chrome://requestpolicy/content/overlay.js Line: 844
which refers to this line:
this._rpService.registerLinkClicked(referrerUri.spec, tabUri);
This was reported in firefox builds forum here:
viewtopic.php?p=7522705#p7522705
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#44
imported trac ticket
created: 2009-10-05 09:07:15
reporter: fung0 and Herrminator
If one is using "base domain" strictness, going to a location with a single-word hostname (e.g. "localhost") results in not recognizing a hostname at all.
For example:
http://localhost/phpmyadmin/
results in the following blocked destinations in the menu:
http://localhost/phpmyadmin/favicon.ico
http://localhost/phpmyadmin/pring.css
...
This bug is the result of the refactoring done to modules/DomainUtil.jsm in r274 where I removed the "fall through" of trying to grab a different identifier from the URI if the default level's logic fails.
Original report (same issue noticed by different users):
http://forums.mozillazine.org/viewtopic.php?p=7648765#p7648765
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#14
imported trac ticket
created: 2009-06-21 17:38:31
reporter: Charlie
When blacklists (#6) are implemented, enable import of blacklisted items from other blacklisting extensions (!NoScript, ABP, etc.).
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#29
imported trac ticket
created: 2009-08-08 19:21:01
reporter: justin
Aus has reported that when using RequestPolicy, all images displayed by the Brief rss reader extension are blocked.
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#50
imported trac ticket
created: 2009-10-26 08:22:54
reporter: cd-man
I would like to be able to allow either full sites (ie. google.com) or just a subdomain of it (www.google.com). Currently if I set "Strictness" to "Full domain" in the preferences, it doesn't whitelist www.google.com, even though I have google.com in my whitelist.
IMHO a modus-operandi more similar to NoScript would be more useful. In concrete terms:
This is useful, because on some sites I trust the whole site (ie. *.google.com), while on other sites I would like to trust only the particular subdomain (blogs hosted on services like blogger or wordpress come to mind - ie. I would like to trust qwert.blogspot.com but not aoeui.blogspot.com :-)).
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#9
imported trac ticket
created: 2009-06-21 17:16:17
reporter: justin
When using stricter classification policies, there are times when users want to whitelist all subdomains of the current domain. After #8 has been completed, displaying menu items for wildcard subdomain whitelisting should either be enabled by default or should be an optional preference when using stricter classification policies.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#22
imported trac ticket
created: 2009-06-21 19:57:54
reporter: Chris Buijs
It would be nice to have an indication that the webpage one is at is in the "allowed" origins whitelist so people realize that every request from this page is being allowed. I suggest turning the flag green when this is the case.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#27
imported trac ticket
created: 2009-08-06 11:28:11
reporter: justin
Some users would like to use only the toolbar button and not have the status bar icon visible at all. This will require being careful with the possibility that users may not have either the status bar icon or the toolbar visible. In that case, they would still have the context menu, though.
We could try to warn the user if they disable the status bar icon when they don't have the toolbar button in use, but that's not perfect because they could remove the toolbar button later. Probably best is to just warn the user when they disable the status bar icon.
Somewhat related to this is #25.
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#12
imported trac ticket
created: 2009-06-21 17:29:41
reporter: Chris Buijs
Add an option to collapse the screen area of all blocked objects (similar to the feature in !AdBlock Plus). This would be for all types of objects, including images.
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#45
imported trac ticket
created: 2009-10-18 05:24:15
reporter: muncho
There are many sites that refer to a bunch of other sites that host avatar images, videos, files, etc. I have also seen a lot of sites that uses CSS files from different domains.
It would be more convenient for the user to just blacklist some sites (like "GoogleSyndication.com") and then use the "Allow reguests from www.site.com" and "Temporarily allow requests from www.site.com" features instead of allowing every other site EXCEPT the sites he/she does not want to.
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#49
imported trac ticket
created: 2009-10-24 00:49:13
reporter: emk
Just a simple typo, but critical.
https://www.requestpolicy.com/dev/browser/src/modules/DomainUtil.jsm#L144
144 if (e.name == "NS_ERROR_HOST_IS_IP_ADDRESS ") {
Please trim an extra trailing space.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#26
imported trac ticket
created: 2009-08-02 19:46:53
reporter: justin
It would be very handy to be able to add/remove items from the whitelist through a context menu available when clicking on items in the request log.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#13
imported trac ticket
created: 2009-06-21 17:32:49
reporter: Nathan Tuggy
Allow whitelisting based on the types of requests/objects (e.g. header redirects, iframes, stylesheets).
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#4
imported trac ticket
created: 2009-06-09 09:27:43
reporter: justin
This is a ticket to contain new items to consider for the initial whitelist offered to users the first time !RequestPolicy runs.
Thursday Dec 22, 2011 at 18:44 GMT
Originally opened as RequestPolicy/requestpolicy#1
imported trac ticket
created: 2009-06-09 07:48:26
reporter: Christoph Langguth
Add an "ignore blocked requests to" option to ignore certain blocked destination domains and therefore avoid showing a blocked content notification when only these destinations are blocked.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#39
imported trac ticket
created: 2009-09-17 16:49:27
reporter: justin
Sometimes a path will show up as an allowed destination hostname in the menu. I finally found a repeatable (for the moment) example of this happening and it appears to be with a 303 Object Moved redirect to a location that is just a path (no protocol + host).
Example with some specifics removed (so you don't know what coupon my wife wanted me to print):
http://coupons2.smartsource.com/smartsource/index.jsp?Link=XXXXXXX
elicited the following Location header in the response:
Location: /YYYYYYY/dcs.gif?dcsredirect=126&dcstlh=0&...
which appears to match what I see in the !RequestPolicy menu.
However, it seems like there must be more to it as one would think this would be fairly common and so the bug would have been visible more frequently. I'll need to come up with a repeatable test case to be sure that this is the issue.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#16
imported trac ticket
created: 2009-06-21 17:49:32
reporter: justin
Add a system of subscribing to whitelists maintained by others (similar to ABP's subscriptions). This would probably also resolve #15.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#25
imported trac ticket
created: 2009-07-26 20:24:43
reporter: justin
If the status bar is not enabled (that is, if one goes to the Firefox "View" menu and disables the status bar), the !RequestPolicy toolbar button does not work. The error that results from clicking on the toolbar button is:
{{{
Error: this._menu.openPopup is not a function
Source file: chrome://requestpolicy/content/overlay.js
Line: 1295
}}}
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#37
imported trac ticket
created: 2009-09-16 07:04:13
reporter: justin
There is a bug that is allowing, on rare occasions, the same destination domain to show in both the "allowed" and "blocked" sections of the menu.
I've noticed this a few times and it has also been reported by two users here:
http://forums.mozillazine.org/viewtopic.php?p=7204365&sid=0281311390631917f73582128be39846#p7204365
I still have not found a repeatable case of it.
Going forward, I think what I'll need to do is add in some code to check for this particular situation and log the relevant info when it happens.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#15
imported trac ticket
created: 2009-06-21 17:46:31
reporter: justin
The initial setup window can be confusing by prompting users to choose regions that have corresponding pre-defined origin-to-destination whitelist items. It needs to be clearer to understand the impact that selecting regions has (sometimes it doesn't appear to change the box showing the items to be whitelisted), as well as which ones a user should select. An entirely new approach is not a bad idea.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#34
imported trac ticket
created: 2009-09-15 08:33:19
reporter: justin
Private browsing mode doesn't currently get special treatment.
There are two major aspects to consider: 1) the whitelist, and 2) the allowed/blocked request information maintained internally so that RequestPolicy knows what to show in the menu.
I think the easiest thing to do that could be considered expected behavior would be to have anything added to the whitelist during private browsing be temporary and have leaving private browsing mode remove all temporarily whitelisted items.
The internally maintained request data is harder to deal with. One option would be to make a copy of internal data when entering private browsing mode and restore that copy when leaving.
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#5
imported trac ticket
created: 2009-06-21 16:31:08
reporter: justin
The only existing way for a user to copy a debugging log snippet (details of blocked/allowed requests) is through a process intended for developers that involves changing values through about:config. At a minimum it should be possible to enable console logging through preferences > advanced. Even better would be a way for users to access this debugging info without having to start firefox from a console.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#41
imported trac ticket
created: 2009-09-22 19:48:06
reporter: justin
The user needs to be notified of a conflict with the Brief extension (#29).
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#33
imported trac ticket
created: 2009-08-28 11:20:00
reporter: TPS
I would like the option to enable/disable each of the prefetch behaviors of RP. Default it however it is now, but I would like the option to keep each of the prefetch options enabled, or conversely, to keep forcing them (each) disabled upon startup & shutdown. If prefecthing can be dynamically activated/disactivated during browsing, maybe also per-load or timer-based options to force them to the above options.
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#47
imported trac ticket
created: 2009-10-23 10:33:08
reporter: kapw
Please add some keyboard shortcuts. It should at least be possible to allow/deny redirect requests (that usually pop up on the top of the window) with shortcuts. Thanks for your efforts!
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#23
imported trac ticket
created: 2009-06-21 20:41:41
reporter: ques
!RequestPolicy ignores the docShell.allowMetaRedirects property. TBE or some addons such as Tab Permissions can enable or disable the property, but after installation of !RequestPolicy, redirects in same host are always allowed.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#20
imported trac ticket
created: 2009-06-21 19:27:04
reporter: justin
There are new translations available for !RequestPolicy at http://www.babelzilla.org/ that need to be integrated.
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#46
imported trac ticket
created: 2009-10-21 21:21:30
reporter: justin
Multiple users have thought that there was something wrong with the Request Log because it is empty when they open it even though they clearly have had cross-site requests being blocked.
My reason for having it not be populated until it is opened is that otherwise it could be harmful to someone's privacy if someone else sat down at their browser session and could see the user's history by looking at the request log.
Here are some options for how to improve this:
There also needs to be a "clear" button added if just closing the request log doesn't clear it anymore.
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#6
imported trac ticket
created: 2009-06-21 16:51:42
reporter: justin
Add a blacklist of request destinations that aren't allowed even if the whitelist policy says they should be. This would apply even when "temporarily allow all requests" is enabled (maybe that would be the default behavior but it could be changed through a config option to not apply in that case).
The blacklist would be able to include IP address ranges and requests to those IP addresses would be blocked even if the host in the requested URI was a domain name rather than an IP address.
The blacklist would definitely be for blacklisting destinations, possibly also for blacklisting origins-to-destinations (though one might argue that if users need to allow destinations from only some origins, they shouldn't whitelist the destination but instead only those origins-to-destinations they intended to allow). What about origins? I seem to really need to stretch to come up with a situation where that would be useful.
The blacklist would probably be accessible by default only from the preferences window but later on there could be an option to add "blacklist this [whatever]" items in the menu.
(Thanks to RSnake for the suggestion of a blacklist.)
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#3
imported trac ticket
created: 2009-06-09 08:14:11
reporter: justin
There is a hidden option to disable auto-reload after modifying the whitelist through the menu. This option should be available in Preferences > Advanced.
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#8
imported trac ticket
created: 2009-06-21 17:11:28
reporter: justin
There is a need to make available wildcard whitelisting, especially for users who have enabled stricter classification policies (e.g. full domain).
This will probably include both the ability to use just a * for a wildcard or use regex if preferred. Care must be taken to avoid users attempting to whitelist items such as 12.34.56.* and losing security as a result of whitelisting more than ip addresses. Allowing/requiring CIDR notation for this would help (at least, it would help the more advanced users -- the average user should at least be prevented from shooting themselves in the foot, though).
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#32
imported trac ticket
created: 2009-08-12 09:19:20
reporter: justin
Adam points out that there should be an "About RequestPolicy" item in the main RequestPolicy menu. This will probably be at the top, above "Preferences".
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#43
imported trac ticket
created: 2009-10-05 08:41:24
reporter: justin
This is an extended and better fix for #35. We should display a message in the menu when the user is at a chrome:// url that tells them they cannot block these requests. It should also take care of not displaying any other meaningless data in the menu in the case of an origin whose requests the user aren't allowed to control.
This is also needed because the change in r275 may actually have a side effect of not clearing items from the menu fully when a page is reloaded, for example.
Thursday Dec 22, 2011 at 18:44 GMT
Originally opened as RequestPolicy/requestpolicy#2
imported trac ticket
created: 2009-06-09 08:05:50
reporter: justin
Some people would like to be able to perform multiple menu actions before the automatic reload of the current page. One good example of this being useful is with mobile devices that have low and costly bandwidth and thus slow reloads that waste data transfer.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#28
imported trac ticket
created: 2009-08-06 13:49:09
reporter: justin
The toolbar button uses a button type that has both the icon button and a separate, smaller button (an arrow) that indicates a drop-down menu. However, clicking on the main button or the drop-down arrow part of the button gives the same menu. We should save space and just use the normal button as long as the two parts of the button do the same thing.
Thanks to Fakir for the suggestion.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#40
imported trac ticket
created: 2009-09-18 06:59:07
reporter: justin
The initial whitelist that users are given the option to import when they use !RequestPolicy for the first time includes only one destination that is allowed from any origin: recaptcha.net. However, Google just bought reCAPTCHA:
So, we need to remove it from the suggested initial whitelist. (In case the reader of this wants an explanation of why this changes things: allowing any site to make requests to a Google property without the user's knowledge is exactly the opposite of what !RequestPolicy should do.)
It's a shame, too, as there are a handful of sites whose registration process is complicated by having reCAPTCHA blocked until after the user already has done some work.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#19
imported trac ticket
created: 2009-06-21 19:05:53
reporter: Vitorio Okio
Add an option in the preferences window to restore default settings.
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#10
imported trac ticket
created: 2009-06-21 17:20:49
reporter: chocolateboy
There should be an option to enable extra visual notification of blocked requests, such as flashing the statusbar icon when it changes to indicate blocked content.
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#21
imported trac ticket
created: 2009-06-21 19:31:24
reporter: justin
Changes have been made to strings in !RequestPolicy since the last time it was submitted to http://www.babelzilla.org/. A new version needs to be submitted.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#35
imported trac ticket
created: 2009-09-15 08:48:04
reporter: justin
!RequestPolicy has to keep data around about blocked and allowed requests in order to display the menu. However, it shouldn't be easy for someone sitting down at an existing browser session to view internal data structures. That is, we can't hide the data from browser data inspection tools, extension development utilities, process debugging tools, memory dumping, etc., but we should at least keep less savvy users from sitting down at an open firefox session and viewing information about browsing history that may not be otherwise available due to history saving being disabled, etc.
Aerik Knapp-Loomis has discovered that using the url chrome://browser/content/browser.xul and then clicking on the !RequestPolicy menu shows a list of visited domain names during the current session.
I don't consider this to be a major issue as plenty of other information from firefox is available to someone sitting at someone else's logged in system. This particular case should be fixed, though.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#31
imported trac ticket
created: 2009-08-12 09:17:05
reporter: justin
In the context menu, the label that says "RequestPolicy" changes color to match the flag icon next to it. Adam mentioned that this can be distracting and so not good for overall usability. I tend to agree. The color of the text in the label should stay black.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#30
imported trac ticket
created: 2009-08-08 19:44:54
reporter: justin
There needs to be documentation on the website, either a wiki page or a website page, to describe what the different strictness settings mean.
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#42
imported trac ticket
created: 2009-10-03 19:02:59
reporter: justin
If one switches between different strictness levels (e.g. "base domain" -> "full domain") the menu for currently opened sites will be wonky. It is possible that items show up that shouldn't and submenus for listed items don't exist. This caused version 0.5.9 submitted to AMO to be rejected:
Hi Justin,
please excuse that I have to refuse this version, it seems that it gets easily confuse on domain rules. I started testing with importing some of the default rules, removed them later, changed to full domain style and allowed youtube.com requests to ytimg.com. I guess your extension can't distinguish if it is a domain or host rule and switching the rule style confuses it. I switched backed to basic domain style and had ytimg.com listed under allowed requests, removed this, but the item is still there, no without the submenu (and other hosts of ytimg.com like i.ytimg.com still show up under the forbidden one).
There are two possible approaches I see for when the user changes strictness levels:
I should try to do the the first one, and if there are unexpected difficulties then just do the second. This is just not a common enough use case to worry about a little odd behavior given the number of more important outstanding features and bugs.
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#7
imported trac ticket
created: 2009-06-21 16:58:49
reporter: justin
There should be a way to allow individual blocked requests rather than having to allow an entire domain.
Possibly this could go in an "Advanced" submenu off of the main menu (maybe put it where "Request Log" is and stick "Request Log" under "Advanced", as well). Another option would be to add a new submenu to each blocked/allowed destination and under there list the specific blocked/allowed requests. This starts to get complicated on the implementation side due to the way RequestPolicy tracks blocked and allowed requests for generating the menu: that is, not analyzing the DOM (well, only a little) and instead keeping track of requests that the browser tries to make and associating them with the url of the current page. The risk of misleading info increases a lot if RequestPolicy is stating what the individual items on the page are without looking at the DOM. So, RequestPolicy would need to look through the DOM very thoroughly.
(Thanks to RSnake for the suggestion.)
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#11
imported trac ticket
created: 2009-06-21 17:26:33
reporter: justin
There should be an option to only have the context menu entry when in full-screen mode.
(This ticket was repurposed, as #87 was a dup and that ticket was resolved, so changing this one to farp's suggestions below.)
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#48
imported trac ticket
created: 2009-10-23 20:57:19
reporter: emk
For example, click http://総務省.jp/.
RequestPolicy will block the request to xn--lhr645fjve.jp.
I've found the following methods in nsIRequestPolicy broke the non-ascii chars.
11 void registerHistoryRequest(in ACString destinationUri);
12 void registerFormSubmitted(in ACString originUri, in ACString destinationUri);
13 void registerLinkClicked(in ACString originUri, in ACString destinationUri);
The parameter type should be AString rather than ACString. ACString will cripple the non-ascii chars from JavaScript caller.
In general, XPCOM components written in JavaScript should use AString because JavaScript strings are encoded as UTF-16.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.