pfn/passifox — pull request #279 by chrahunt (2014-05-30 15:03:42+00:00)
Title: Block specific pages

This is unfinished, but I think now is the appropriate time to get feedback.

This partially addresses #258 and addresses #267 and #171, which are all concerned with excluding actions on specific pages. My implementation adds a section to the chromeIPass options page that allows users to add URLs/patterns that are matched to the full URL of the page being viewed. Two methods of matching are supported:
* Regular expressions
* A simpler syntax that uses * as a wildcard

If this solution seems to be on the right track w.r.t. the issues mentioned above; there were a few other items I intended to address:
* Right now this essentially removes the ability for chromeIPass to interact with a matched page, but I would like to extend this to prevent KeePass queries on activation of the tab holding the blocked page as well, which would prevent the KeePass password request dialog and fully address #258.
* Syntax error handling and general input validation when a new pattern is being added.
* Allowing addition of pages via browser action popup. Pressing a button in the browser action popup would bring up a dialog box that would allow editing and addition of a pattern (which would be initially populated with the current page's full URL).
* Browser action icon and popup reflecting the current page's block status.
* Temporary suspension of block status. If the user wishes to temporarily suspend the block on the current page
* See pattern that is resulting in a page being blocked. Clicking a button on the browser action popup would bring the user to the options page with the 'Block Pages' tab selected and highlight the row with the rule that matches the current page.
* Better handling for pages with iframes. Currently the content script is invoked once on page load for the parent page and at least once if there is an iframe (in the context of that iframe); I have not tested the number of pages. This 'double-invocation' causes an issue because the `document.href` attribute is the location of the iframe, which may not match the pattern intended to prevent action on the current page.

Additionally, this lays the framework for a solution to #245 and #271. At least, the same concept of matching the URLs could be used to specify pages on which to block autofill (but still allow for action when the credential input field is selected).