Tiny cleanups in onBeforeRequest

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Optimize onBeforeSendHeaders

This function makes little sense to me. I think the logic originally was:

If we lose the race to update cookies in onHeadersReceived, we can win it now in
onBeforeSendHeaders.

Unless I'm missing something, I think this *whole function* might be completely useless.

I'll open up an issue to discuss that in a bit.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Let developers know about DEFAULT_LOG_LEVEL.

Since we are much more silent, let anyone who opens the console know that
DEFAULT_LOG_LEVEL can be adjusted to debug rules, etc.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Drop trailing comma errors that break Closure, etc.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Move redirect loop detection to prior block

No sense in testing the redirect counter right after we set it.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Fix some tiny but annoying jslint errors

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
High-severity messages accidentally logged twice

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
[Stack-Exchange] Add mixedcontent rule for search
Remove onHeadersReceived listener

The onHeadersReceived listener served one purpose:
Secure cookies set via HTTPS (not HTTP, not JS)

This task is already handled by:
- onBeforeSendHeaders (blocking) which should secure cookies
- onCookieChanged (non-blocking) which secures any cookies on create/update

Moreover, the current function is broken:
- We look for a case-sensitive "Set-Cookie," but many servers send only a
lowercase "set-cookie" (e.g. Google, Twitter, ...)
- "; Secure" is frequently not the end of the cookie (old #L192)

By removing this function, here's what happens for different cookie types:

- Set by HTTP
No change, wasn't ever handled by onHeadersReceived

- Set by Javascript
No change, wasn't ever handled by onHeadersReceived

- Set by HTTPS
Now (as before) secured by onCookieChanged (non-blocking, so maybe a tiny
window for a race to steal the cookie, but ...)
Secured by onBeforeSendHeaders (blocking)

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Update comments

Old comment bug was fixed a while back in Chrome.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Faster escape from onBeforeRequest when nothing applies

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Don't try to update the URI() object unless needed (rare)

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Remove useless displayPageAction handlers

We call displayPageAction all the freaking time.

It's called in chrome.tabs.onUpdated which takes care of 99.9% of all cases.

These two are unnecessary.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Add some comments explaining functions

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>

Conflicts:

	chromium/background.js
Move displayPageAction out of the hot onBeforeRequest

displayPageAction is called (unnecessarily) potentially /hundreds/ of times per tab.

It only needs to be called /once/ when a page updates and has applicable rules.

We'd be fine just removing it from onBeforeRequest (and depending on chrome.tabs.onUpdated) except for the super-edge case where a tab:
- Meets zero potentially applicable rulesets
- Has absolutely no rulesets that apply to dependencies (included JS, etc.)
- Makes a request we /can/ apply rules to, but it happens after DOM document complete when tabs.onUpdated has already fired

In practice, I was unable to find *any* sites that met this criteria, but I can make a localhost test case.

This adds a 10 sec. timer to check if active tabs are missing the pageAction icon.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Revert "Move displayPageAction out of the hot onBeforeRequest"

This reverts commit 1d5df8f3204aac85618a1b8b21629dc9fbaaa791.
Fire pageAction only from tabs.onUpdated/onReplaced

pageAction is responsible for adding the HTTPS Everywhere icon next to the URL bar. We used to display this only on pages w/ applicable rules (almost every page), but that logic was messy and slow. Now we display the icon all the time.

This might get called once or twice per-tab, but it's relatively low cost. At least we're no longer calling it multiple times for every request :)

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Reload the selected tab when a rule is toggled

This mimics the behavior of the Firefox addon.
Usually someone is trying to test whether disabling
a rule fixes some bug on the site, in which case
they would want to reload it anyway. We should
just do it automatically.
Simplify onBeforeRequest a little bit and remove call into the DOM.

Conflicts:

	chromium/background.js
Fix tmpuri references