This logic should never have been in settings.coffee. This moves it to completion.coffee, where it belongs.
If an exclusion rule depends on the hash/anchor, then we're not picking it up. Here's a concrete example of this: - https?://ca*.computing.dcu.ie/[0-9]*-*#* (which matches slides prepared via "slidy"). The initial URL does not include the anchor/hash, so we miss the exclusion rule. The page is bounced immediately to an anchor/hash for which the rule should apply, and we miss it. (There may be other ways in which the URL can change (WebNavigation?), we need to look into this.)
When the active tab changes, we call updateActiveState to update the icon and propagate any changed exclusion-rule state to the tab. All frames received the request. However, only one response is received by the background page. Therefore, new exclusion rules are only propagated to one frame. Here's what can go wrong... On gmail, open the hangouts frame. Add an exclusion rule sepcific to the hangouts frame. Save it. The update is propagated only to the main frame. The new exclusion rule is not in effect in the hangouts frame. That's wierd and obviously wrong. In this commit, every frame receiving the getActiveState request also calls checkIfEnabledForUrl to ensure that any new exclusion-rule state is propagated. This is overkill, to some extent. We should really move settings to chrome.storage and have each frame check locally for changes affecting it.
Previously, we have been populating the suggested exclusion URL in the page popup with the tab's URL. This uses the active frame's URL instead: - because this is the URL which will affect the current frame (without this, a user can naively add an exclusion rule and it has no effect), and - because, without this, the user has no reasonable way to add exclusion rules for frames such as the hangouts frame on gmail (for which, the URL is not displayed in the address bar).
This is @mrmr1993's work from #1041. Reload content scripts when vimium is installed or updates. (@mrmr1993: The automatic merge was really messy (or, at least, I couldn't figure out what was going on). Since the bulk of #1041 was actually quite compact, I took the liberty of just copying it in. Hope you don't mind.)
This delivers a "hidden" massage to the vomnibar after the vomnibar has been hiddent in the host page. The vomnibar only performs whatever action is required when it receives this "hidden" message.
This is not entirely satisfactory. It would be great if a delay of 0 worked (a la `nextTick`). But it seems we need a little longer because we need to allow the UI component messaging to complete. An alternative would be to thread the action required through the UI component logic. But that's pretty ugly too. Yet another alternative would be to have the UI Component post an "ok, we're done, do it" message once the UI component has been removed. Fixes #1485.
Click: - in the vomnibar focuses the input - anywhere else (such as in the space below the vomnibar) hides the vomnibar. This makes clicks in the space below the vomnibar behave the same as clicks in the page itself... Which makes sense, because the difference is not apparent to the user.