{"issue":{"title":"switching between strictness levels confuses menu","user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7"},"milestone":null,"created_at":"2011-12-22T02:32:34Z","labels":[{"name":"extension","url":"https://api.github.com/repos/RequestPolicy/tractest/labels/extension","color":"ededed"}],"state":"open","updated_at":"2011-12-22T02:32:35Z","id":2632254,"html_url":"https://github.com/RequestPolicy/tractest/issues/42","closed_at":null,"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"body":"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:\r\n\r\n  Hi Justin,\r\n  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<number>.ytimg.com still show up under the forbidden one).\r\n\r\nThere are two possible approaches I see for when the user changes strictness levels:\r\n  1. Go through and fix up the _rejectedRequests and _allowedRequests objects based on the new strictness level, resulting in the menu working normally after the change.\r\n  1. Just clear out the _rejectedRequests and _allowedRequests objects, resulting in the menu not having anything in it for already-open sites.\r\n\r\nI 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.","number":42,"url":"https://api.github.com/repos/RequestPolicy/tractest/issues/42","comments":1,"assignee":null},"comment":{"user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7"},"created_at":"2011-12-22T02:32:35Z","updated_at":"2011-12-22T02:32:35Z","id":3242852,"body":"[justin] Fixed in r290.\r\n\r\nWe clear the allowed/rejected data rather than try to fix it up because there really is no way to fix it up correctly based on a new strictness level without trying to apply whitelist rules and other funkiness.\r\n\r\nAlso added a description of the Strictness setting in the preferences menu and an attempt to warn about the menu being cleared when it is changed. I'm not sure the text is the best, but it's hard to convey these ideas concisely.","url":"https://api.github.com/repos/RequestPolicy/tractest/issues/comments/3242852"},"action":"created"}