| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
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 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 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).
|
|
.. and don't forget to actually use the incognitomode flag in the front
end.
|
|
See #1495.
|
|
|
|
Rationale. There are really two insert modes: the one we activate with
"i" and the one that's activated when a focusable element receives the
focus. This makes that distinction clearer. And, in particular, it
means that, when the latter type of insert mode is active, we *know*
that gloabl insert mode is *not* active.
|
|
|
|
Doh! I didn't know this existed.
|
|
The lack of a callback here was causing errors when loading (at least)
the options page.
|
|
- Fix incorrect camel case in option name.
- Better text on options page.
- Loud comments re. using option directly from chrome.storage.sync.
|
|
|
|
- add new option "GrabBackFocus"
- use chrome.storage.sync.get() to get option value
- avoid race conditions on load
- fix tests
|
|
If an input grabs the focus before the user interacts with the page
(keydown, mousedown), then grab back the focus.
TBD:
1 This requires a new option, which has not yet been added. For now,
it's just permanently enabled.
2 There's a race condition between the setting being loaded and the
element being focused. Currently, this defaults to being activated.
This is the wrong thing to do. The solution is probably to use
chrome.storage for the setting.
3 The tests fail (because of TBD-2, above).
|
|
When we exit visual mode with "y"...
"y" is a command for visual mode. Currently it clears the selection.
Because it's executed as a command, scrollIntoView is called after
running the command. Because the selection is cleared, scrollIntoView
found nothing to scroll, and was creating an error.
So we need to check whether there's anything to scroll into view, before
trying to scroll it.
Also fix mis-named file in the tests.
|
|
- Show the URL in the HUD (improved quality of feedback).
- Change HUD delay from one second to two seconds - I find one second
too short for the message to be useful. It's often gone before I look
to check. And two seconds (hopefully) isn't so long as to be
annoying.
|
|
Conflicts:
background_scripts/main.coffee
|
|
|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
lib/keyboard_utils.coffee
|
|
|
|
|
|
|
|
Approach:
- We never save the find mode history from an incognito tab in the
settings, instead they are saved in the tabMapInfo for each
currently-active incognito tab.
- When a new incognito tab (or page, after navigation) starts, we
scan the tabMapInfo looking for the find-mode history of any active
tab.
In this way, the history is shared between incognito tabs, but discarded
once the last incognito tab closes.
|
|
|
|
|
|
The approach is to maintain the "current" history in every tab, adding
queries from other normal tabs in all tabs, but only saving queries from
non-incognito mode tabs.
So, queries from non-incognito mode tabs propagate everywhere, whereas
those from incognito tabs never leave the tab.
|
|
|
|
- This commit is incomplete because, to progress, we need bc7db7473456713c8c84f324e71da93145ffa2a0.
|
|
|
|
|
|
|
|
Doing the migration in a content script is dumb. Now we do it on the
background page.
|
|
I'm seeing a strange scrolling bug on some pages, for example, here:
http://www.steephill.tv/tour-of-qatar/.
Background:
When we scroll, we first have to decide which element to scroll.
Because of a chrome bug, we do this by testing candidate elements:
scroll the element up by one px, then back down again. If it moved,
then it's scrollable, and it's the element we should scroll.
Bug:
In some cases, the micro-scroll-up succeeds, but the subsequent
micro-scroll-down fails. It's not clear how this could happen. It
may be a chrome bug. In any case, as a result, we conclude that the
element is not scrollable, and proceed to the next candidate. We end
up finding no scrollable element, and j/k scrolling is broken. If
you press-and-hold "j" or "k", you can see the repeated
micro-scroll-ups.
Problem:
I can't reproduce this in a clean chrome account. I only see it in
my live chrome instance. I've tried disabling all extensions, but
the problem persists. So there's something else at play, but I
haven't yet been able to track it down.
Solution:
This commit is a temporary workaround. We just default to scrolling
document.body if we can't find anything else to scroll. Most of the
time, that's the right thing to do. And it's what we would have done
prior to implementing smooth scrolling. Nevertheless, it isn't a
great solution...
Notes:
It's possible that this is related to #1117. However, users there
have reported *not* seeing the micro-scrolls. So probably not.
I'm not posting this as a PR, because I can't reliably reproduce the
bug. However, the fix pretty much does what we did before smooth
scrolling, it's almost certainly safe. So I'm just pushing this
straight into master.
|
|
- convert getCaretCoordinates from JS to CS
- handle x axis in scrollIntoView
- better comments throughout.
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
which was broken.
|
|
There's considerable discussion in #1441 as to what we should do with
the selection on leaving visual mode. Good arguments have been made as
to why we should keep the selection. However, at this point,
keep-it-simple seems like the best strategy, and wholly removing the
selection (probably) provides fewer ways for the user to shoot
themselves in the foot.
|
|
This effectively reverts 95e086563b918364d3038f6489cc97c73fcb7180
(Escape-Escape clears selection) pending discussion of the right UX
around exitng visual mode.
|
|
This reverts commit c1681fea2f2629c6bee1e27c5dfc704d77553d96.
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
When caret mode guesses a selection score text nodes by their visible
area and the number of non-whitespace characters they contain. Choose
the first non-whitespace character in the highest-scoring node.
The intention is to avoid making a poor choice for the initial caret
position.
|
|
|
