| Age | Commit message (Collapse) | Author |
|---|
|
We track the URL of the active frame in each tab so that we can
correctly populate the rules in the page popup.
Previously, we tracked URL changes only on focus events. This commit
moves that to isEnabledForURL, which is also called when the URL changes
as a result of web navigation.
|
|
|
|
https://github.com/mrmr1993/vimium into mrmr1993-exclusion-rules-pushState-and-hash
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
focus-main-frame-merge
Conflicts:
content_scripts/vimium_frontend.coffee
Also rework to remove dependency on Chrome 41+ sendMessage API
(specifically, relating to optional target frameId argument).
|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
|
|
The event listeners were registered late, potentially allowing the page
to get priority over us for key events, etc., when:
* the original URL was disabled by an exclusion rule
* the URL was changed
- without a page load (by history.pushState or modifying
location.hash), and
- the new URL isn't (completely) disabled by any exclusion rules.
This forces the event listeners to be registered even when the
current URL is disabled, to avoid this problem.
|
|
This uses the chrome.webRequest API to detect changes to page URL which
*do not* cause the content script to refresh.
|
|
|
|
1. Rework event handling to eliminate frame flicker (a la #1485).
2. Tidy up logic. Which should make this more robust.
|
|
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.
|
