| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Perform background commands on the requesting tab (v2)
|
|
There's no need to have the previous unusual calling style (passing the
arguments as a list. It looks more natural to pass tham just as regular
arguments, as here.
|
|
We pass the count to *all* front-end commands. All of the commands
which don't use a count, just ignore it.
|
|
|
|
With this change, now *every* front-end command either accepts a count
argument, or or it doesn't accept a count at all.
|
|
|
|
The question here is where to callapse the selection to, anchor or
focus?
When exiting visual mode, mimic vim. When trasitioning between visual
and caret modes, do what's right to keep the selection in the same
place.
This also adds some related tests.
|
|
This is a better way of stubing for the tests.
Previously, if anything went wrong, there would actually be a visual
effect for the user (the page would scroll). This way, that cannot
happen.
|
|
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.
|
|
|
|
In #2053, I omitted to notice that the top-frame (vomnibar)
initialisation sequence also generates O(n^2) messages.
This makes that sequence O(n).
|
|
|
|
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.
|
|
|
|
|
|
There's no need for the setting of the icon to be driven from the
content script. We first know the enabled state in the background page,
so set the icon there immediately.
|
|
This tidies up some logic that was showing its age.
|
|
|
|
|
|
|
|
|
|
Now that we've moved Frame.init() back to before checkIfEnabledForUrl,
there's no longer a need to check that frameId has been initialised. It
must have been.
|
|
|
|
The intention is to move checkIfEnabledForUrl to the frames port. That
needs to run pre domReady, so first -- here -- we separate the two
ports.
|
|
|
|
Use `onConnect()`, the `domReady` port and `onDisconnect()` to track
the frames within a tab.
|
|
When the scrollers `activatedElement` isn't scrollable, we currently
search up the DOM tree for the next scrollable thing, and stop at
`document.body`. However, it can be that that isn't scrollable.
When that happens, this commit searches for a scrollable element in the
same way as it does when the frame initially loads. This makes it
possible to restart scrolling on pages like this one:
- http://redux.js.org/docs/basics/UsageWithReact.html
after clicking one of index links.
Inspired by example posted by @marlun in #425.
|
|
This adds tests for a couple of properties that are required of alphabet
hint strings.
|
|
Oversight from #2022.
|
|
Problem:
- `?`, `o`, `Esc`, `Esc` leaves the focus in the (invisible) help dialog
frame, rendering Vimium broken.
Since we do
@iframeElement.focus()
when we activate a UI component, here we do
@iframeElement.blur()
when hiding such elements.
Fixes #2038.
|
|
|
|
|
|
|
|
This addresses the potential race condition mentioned in this commit
record (3542db7b6c322d803c263db641ae0b02327447ca) and in #2033.
In non-top frames, wait until documentReady before sending the message
to initialise the Vomnibar. This cannot be before preDomReady in the
main frame, right?
|
|
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.
|
|
This reverts commit 7774beb6643c0d905f9caba4345453790af948ad.
Reverting this. It can be done better (and capture some other incorrect
cases).
|
|
With #2022, we can now implement normal-mode key-handling tests.
Writing these tests uncovered the bug behind 7774beb6643c0d905f9caba4345453790af948ad.
|
|
E.g. `7gj` should be `1j`; currently it's `7j`.
|
|
|
|
|
|
|
|
|
