| Age | Commit message (Collapse) | Author |
|---|
|
Previously, we set a variable `delay` and then did some logical
gymnastics to get the correct effect.
However, in fact, all we care about is whether the user might over-type
the links text. So changing to using that as a Boolean flag greatly
simplifies the logic. And we lose about 10 LoC.
|
|
While we're changing this code, we can renamed the parameter here to be
consistent with its naming elsewhere.
|
|
Somehow,
|
|
Previously (quite some time ago) we reused the LinkHints object. But
for some time it's been a class, and we never reuse instances.
Therefore, we can remove the code related to resetting the object's
state.
|
|
Previously, the exit sequence when a link was "clicked" was spread over
several functions with several callbacks. This made it difficult to
verify that the correct actions were happening in the correct order.
Indeed, they weren't in at least one case (we were still showing hints
while "waiting for enter").
This fixes that by putting all of the various deactivation orders into
one place, `@activateLink()`, and simplifies `@deactivateMode()`
accordingle.
|
|
|
|
We were immediately restarting link-hints mode if a count was present.
Unfortunately, that meant that we were detecting our own link-hint click
and exiting immediately. So, with a count of 6, we were only getting 3
link-hint activations.
To avoid this, we add a short delay (just nextTick).
Also, move some other stuff arund to make sure this works in all cases
(e.g. wait-for-enter).
|
|
The default (for when no options are provided) is of the wrong type.
This works as is, but should really be fixed -- as here.
|
|
Refactor focusFrame - Fix #2023.
|
|
Pass to count to scroll commands.
|
|
Only the `flashFrame` part needs to be guarded against the DOM being
ready. So we can take the `flashFrame` part out as a regular function.
Fixes #2023 (although I don't fully understand why that's happening).
|
|
Add install date to logging page.
|
|
Currently, `10j` keeping `j` held down scrolls quickly for a time then
reduces back the regular hold-`j` scroll speed. Therefore, the user
cannot use a count to influence the smooth-scrolling scroll speed.
This PR fixes that by passing the count to the scroll functions.
Consequently, we adjust the actual scroll amount (which affects the
scroll speed) rather than calling the scroll commands several times
(which doesn't).
|
|
This is no longer necessary since the help page is in an iframe.
|
|
Make behaviour match LinkHints for goPrevious and goNext
|
|
Remove outdated blacklist in DomUtils.isEditable, use DomUtils.isSelectable
|
|
|
|
This stops us from throwing errors when document, window, etc. end up
being passed into DomUtils.isSelectable.
|
|
This fixes #1964.
|
|
|
|
PhantomJS (2.1.1)".
URL: https://github.com/philc/vimium/issues/1944
|
|
|
|
|
|
Oversight from #1958.
|
|
Omitted from #1961.
|
|
|
|
This implements a poor-man's build info.
See #1352. Unfortunately, that requires a separate build target, and
does not work with `cake autobuild`.
This just records the *install date* and displays that info on the
logging page. "Install date" because we can reliably determine it, and
because it does answer the question *have I upgrade Vimium on this
machine since last week?*. And on the logging page because that's out
of the way, and not part of the regular Vimium interface.
|
|
If text.length is 1, here, then we divide by `log 1` - which is zero.
So add one.
|
|
We need to multiply by `count=N` *before* checking `repeatLimit`.
Tweaks #2001.
|
|
With #2006 and #2009, this is no longer being used.
|
|
Remove (unused) `tabInfoMap`.
|
|
Conflicts:
background_scripts/commands.coffee
|
|
Fix `<count>removeTab`.
|
|
Previously:
map J scrollDown count=NotANumber
would break the command completely.
Fixes an error introduced in #2001.
|
|
Use for (not for own) when iterating over an event's properties
|
|
Moving to for own broke find mode history (and thus also next/previous).
This reverts that part of commit
56fed2ac6663d99ca03023f3ffa313c51de5fe32.
|
|
Specifically, avoid reliance on `chrome.tabs.onSelectionChanged`.
If we merge this and #2006, then we can delete all of the
`chrome.tabs.onSelectionChanged` code.
|
|
|
|
|
|
|
|
We were incorrectly setting `options.count` to `NaN` if there was no
command option.
|
|
This fix the problem that `chrome.tabs.onActivated` won't be triggered
when we switch Chrome windows.
|
|
There's a nasty little bug in `removeTab` when you remove more tabs than
there are in the window (and there is a second window):
- all of the tabs in the currently-focused window are removed
- then, later (so, time passes), when you change tab in the other
window, we begin removing tabs again!
The source of the bug is our reliance on
`chrome.tabs.onSelectionChanged`, which doesn't first when removing the
last tab in a window (and there is another window).
Regardless, the previous semantics of `<count>removeTab` was
questionable. It was preactically impossible to predict which tabs
would removed. This picks the current tab, then those to the right of
the current tab, then those to the left.
|
|
|
|
It appears `tabInfoMap` (and related machinery) is not being used. This
removes it.
|
|
|
|
Make `moveToNewWindow` accept a count.
|
|
|
|
|
|
Add count command option
|
