| Age | Commit message (Collapse) | Author |
|---|
|
Remove reference to unused setting "vomnibarInTopFrame".
|
|
|
|
If the element does not have an HREF, then we shouldn't be offering to
copy it's link.
|
|
Note: We probably shouldn't be offering these links at all.
|
|
|
|
|
|
Fixes #426.
|
|
|
|
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
Vomnibar commands are handled in a frame even is isEnabledForUrl is
false.
|
|
|
|
|
|
|
|
Return to the original viewport (when no find matches)
|
|
|
|
|
|
When there is no find-mode match, return to the original viewport. This
is a better UX in visual mode, because the text the user is searching
for is often on within the viewport.
(This is also more vim like. We could consider *always* working this
way.)
|
|
Previously, we removed the selection on exiting visual mode. This
collapses the selection instead.
My own experience with visual mode suggests that this is better. In
particular, if we remove the selection, then when the user re-enters
visual mode, they're dropped into caret mode. It is unlikely that the
default caret position selected by caret mode is better than the last
text selected by the user in either caret mode or visual mode.
|
|
|
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
|
|
Clean up, and fixes following code review from @mrmr1993.
|
|
|
|
|
|
|
|
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
|
|
|
|
This changes vomnibar commands to activate not in the current frame, but
in window.top. Consequently, the vomnibar always appears in the same
position, and we don't get odd looking vomnibars in small frames.
Apart from the better UX, this seems to be the right thing to do.
Vomnibar commands apply to tabs (not frames).
Currently incomplete:
- On exit, the focus is not returned to the frame which originally
had the focus. (It's returned to window.top).
- The vomnibar can lose the focus and not hide itself for various
frame/click combinations.
|
|
|
|
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 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.
|
|
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.)
|
|
|
|
|
