| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
We're asking for the "notifications" permission. I'm not sure what
happens. If the user is asked to accept the permission, then we
wouldn't show the notification until the next time Vimium starts.
Instead, we check more frequently. So the notification will show the
next time a tab is created (or changes page).
|
|
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
|
|
"pages/blank.html" was being sent to the default search engine by
chrome.tabs.create().
Not fully functional. New tabs created from incognito mode are created
in a non-incognito mode window.
|
|
|
|
Setting the page icon is now driven from the corrently-active frame.
- Eliminates a race condition.
- Icon matches actual frame state (not tab URL state).
- Exclusion-rule changes propagate to all frames.
|
|
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).
|
|
In b05276ed8264e5a71f20a7068690ba2a414ee6d8, I inadvertently moved the
focus handler from window to document. As a consequence, detectFocus
(now registerFocus) wasn't being called when expected.
|
|
In b05276ed8264e5a71f20a7068690ba2a414ee6d8, I inadvertently moved the
focus handler from window to document. As a consequence, detectFocus
(now registerFocus) wasn't being called when expected.
|
|
Move Scroller.init() up the handler stack.
|
|
Move scroller initialisation so that its key handlers are above insert
mode in the handler stack. This ensures that the scroller sees keyup
events if we enter insert mode while continuous scrolling.
Fixes #1526.
|
|
We should not inject content scripts on chrome upgrades.
|
|
The page (or another extension) sees keydown events (such as shift)
before entering link-hint mode. So we need to also pass the
corresponding keyup events.
Fixes #1522.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Fix oversight from #1517.
|
|
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.
|
|
|
|
|
|
Mainly fix the indentation on comments. Also tweak wording a bid.
|
|
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.
|
|
Fixes #1506.
This takes the opposite approach to #1511. Instead of hiding the
vomnibar when it blurs, we hide it when it's host frame is focused.
|
|
This is a quick fix only (to keep master in a functional state).
openUrlInNewTab is broken, and needs to be refactored.
|
|
|
|
|
|
|
|
|
|
|
|
This only effects link hints with "Use the link's name and numbers for
link-hint filtering" enabled.
We have been matching the *entire text content* of each link-hint
element.
With two (or more) hints, and with one of the elements a descendent of
the other, we have been using the entire text content of the outer node
(which includes the text content of the inner node). This leads to odd
situations where the inner element cannot be selected just by typing its
text, because its text is a substring of the outer element's text.
For example, on Google calendar, the "Today" button shows up as two
hints, one inside the other. Typing "today" never disambiguates the
hint. You always have to hit enter.
There's another nasty example on feedly, where an outer container is
clickable, but its text contains all of the (many) texts of the (many)
contained links. So the hint always has to be selected manually.
Here, when generating the text for an element, we exclude the texts from
any descendent node which has already been considered.
|
|
- This fix enables `2t` to open two new tabs, even in incognito.
Include callback in the call chain so that numbered commands can work.
|
|
This adds another handler which is delivered to the options page, but
for which there is no handler. This was causing an exception on the
background page (console).
|
|
Following on from c8d984520f5de4b3e702cee992c7ecc4f4f49435, I forgot to
fix up the other call to setBadge.
|
|
Fixes #1491.
|
