| Age | Commit message (Collapse) | Author |
|---|
|
The coverage here is far from completem but we do catch the basics.
|
|
While working on the visual-mode code, it became apparent that our
current "singleton" implementation is unnecessarily complicated.
This simplifies it. The keys are now required to be strings.
(Previously, they could be any object; which meant we needed to gove
objects an identity. All of which was complicated.)
|
|
- Refactor the three visual-mode modes.
- Use the key-handling framework from #2022.
- Strip some legacy edit-mode code.
- Rename the file (the old file name was misleading).
- Add "aw" and "as", previously we had the code for this from edit mode.
|
|
This previous file name was chosen when we (I) had the intention of
implementing edit mode too.
That initiative has been abandoned, so the file name is inappropriate.
Renaming now in preparation for a significant refactoring of visual
mode.
|
|
We have:
window.XXX = XXX = -> ...
in many places. This commit reduces the number of these, and moves the
exports to the end, where a single comment explains why they're being
exported.
|
|
The front-end initialisation sequence has become quite confused.
This simplifies it, makes things which must be idemtpotent explicit and
renames some functions to make it clear when they run. It also avoids a
situation where we were possibly installing a `domReady` function to
initialise the HUD multiple times.
Should be a no-op functionality wise.
|
|
The intention is to use this to clean up some of the initialisation
sequences in the front end.
|
|
This tidies up some logic that was showing its age.
|
|
|
|
|
|
|
|
|
|
... they were in the wrong place (and were being run twice).
|
|
This code has been written to test both hints modes, however we were
actually only testing one of them!
|
|
- key handling
- filtered hints - scoring
- filtered hints - tab
- link hints - changing mode
Also, correct the argument ordering in several assert.equal() calls.
|
|
This adds tests for a couple of properties that are required of alphabet
hint strings.
|
|
HUD: Initialize only when the frame receives the focus and Vimium is enabled.
Vomnibar: Initialize in the top frame when Vimium is enabled in *any* frame.
Warning: There may be a race condition here. Specifically, if Vimium
is disabled in the main/top frame (T) but enabled in another frame (A), then the
initialisation could happen in frame A before frame T is listening, so
frame T would miss the initialization message (which is only sent once).
Message listeners are installed early (and probably installed first in
the main/top frame), and the `isEnabledForUrl` messaging takes some
time, so perhaps it's OK. But it *is* a race condition.
Fixes #1838.
|
|
`7gj` should be `1j`.
Also, with:
map ab SOMETHING
`7aab` should be `1ab`.
Replacement for 7774beb6643c0d905f9caba4345453790af948ad.
|
|
With #2022, we can now implement normal-mode key-handling tests.
Writing these tests uncovered the bug behind 7774beb6643c0d905f9caba4345453790af948ad.
|
|
|
|
It makes more sense to pass the passKeys directly to normalMode. So, do
so, and remove the trackState mode option - which isn't otherwise being
used.
|
|
|
|
Previously, the key-handling logic (keyQueue, etc) was and the backend
whereas passKeys were handled in the content scripts - so they were a
long way apart.
Now that they're in the same place, it makes more sense to integrate
passKey handling into the regular key handling, because they depend upon
the same data structures.
|
|
... and fix two bugs:
- not suppressing keyup event after keyChar matched in keydown.
- we cannot check the passKeys keyChar in keyup because the key state
has changed; so we track what the next keyup response should be.
|
|
The styles guide says not to use standalone `@`. So this changes the
occurrences I could find (with sed) to `this`. Occurrences within files
with major outstanding PRs are omitted.
|
|
|
|
PhantomJS (2.1.1)".
URL: https://github.com/philc/vimium/issues/1944
|
|
|
|
|
|
Certain background-page utilities are actually shared, and are therefore
best placed in place that reflects that.
Here, tabRecency is moved to the new gb_utils.coffee in preparation for
implementing a go-to-previous-tab command. In particular, it is no
longer appropriate that tabRecency be embedded within the completion
code.
logMessage() from main.coffee is also a candidate for moving to
bg_utils.coffee.
|
|
This tweaks @mrmr1993's logging ideas discussed in #1629:
- Do not generate log entries from the logging page itself.
- Use the logger for *all* logging (including from `commands.coffee`, and from `bgLog`).
@mrmr1993's original idea is 91fb337c9d92f6291ef42c55c4d29ca35b710203.
|
|
|
|
Previously, we blocked keyboard events for a fixed 200ms.
With this PR, we continue blocking keyboard events until 150ms after the
last `keydown` or `keypress` event. So, we wait until we think the user
has stopped typing.
Fixes #1842.
|
|
|
|
|
|
Don't decode javascript URIs on Chrome 46.0.2467.2 and later
|
|
JavaScript's sort function is not stable; this PR makes the sort used for filtered link hints stable.
There are two reasons for doing this:
- High-scoring hints are more likely to keep the same hint string as the user continues typing. (Currently, the hints assigned change based on the vaguaries of the non-stable sort.)
- For equal-scoring hints, we retain the visit-child-before-parent ordering (which is used to NOT match a parent's text if we have already matched that text in a child).
And, as a result of all of that, the UX is more predictable and hence better.
|
|
The fix for Chromium issue 483000 landed in this version, so it is no
longer necessary for #1611
|
|
|
|
|
|
This prevents issues like #1731 and is an (better) alternative to #1732.
|
|
(@mrmr1993: This is yet another approach to the Settings problem.)
With the new Settings implemetation, settings which have a non-default
value and which are not in synced storage (that is, they have not been
changed since synced storage was introduced) are not currently
accessible to content scripts. This commit makes such settings
accessible via chrome.storage.local.
Important:
- There's a change to the established settings data model here.
Previously, settings with default values were not stored; here, they
are. This eliminates a considerable amount logic from Settings, but
means that migrations will be required if default values are changed
in future. (Other than type changes, have we ever changed a default
value?)
- There's also a change (bug fix?) to the behaviour when an affected
setting is reset to its default value. Previously, the change would
*not* have been synced (whereas all other changes are). Here, such
changes *are* synced. The previous behaviour was inconsistent with
the syncing behaviour of all other options changes.
Note:
- This isn't particularly well tested. It's being committed mainly just
for consideration of the approach, initially.
|
|
|
|
(Not sure when this crept in.)
We need to ensure that we always generate the same hint strings for the
same filter state. Here, we do this by always using the same mechanism
(@filterLinkHints) to set the hint strings.
|
|
Functionality wise, this is a no-op. However, since we now create a new
LinkHintsMode object on every "f", we don't need to be so careful about
resetting the state on exit.
|
|
|
|
LinkHints.init() isn't doing anything.
|
|
This is a minor re-working of #1705 from @mrmr1993.
The main changes are:
- Simplify initialisation logic.
- Always initialise Settings immediately and automatically (ie. don't
initialise Settings separately and manually in the background,
content scripts, options and tests).
- Get rid of addEventListener (it's only being used for on "load").
- Add Settings.use() in its place.
|
|
|
|
Direct keyboard access to custom-search engines via keyword flag
|
