| Age | Commit message (Collapse) | Author |
|---|
|
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`.
|
|
|
|
|
|
|
|
|
|
|
|
This is a no-op.
|
|
This generalises the mechanism by which commands are always run in the
tab's main/top frame. Currently, that's just the Vomnibar.
This is a precursor to moving other UI components to the main/top frame.
It should be fairly trivial to move the help page to the main frame.
The HUD might be trickier.
Mention: @mrmr1993.
|
|
If we just use the name `background` instead of `isBackgroundCommand`,
then we can simplify the building of registry entries.
This is preparitory to adding a new registryEntry field: topFrame;
initially just for the Vomnibar, but thereafter for other UI components.
|
|
This reinstates the feature whereby we disable the content script when
we lose contact with the background page, e.g., on upgrade.
From my investigations, this doesn't appear to be absolutely necessary.
Nevertheless, it's cleaner like this.
|
|
Normal mode updates the pass keys every time the frame changes (so, also
every time we change tab). Here, we reset the key state too. Resetting
the key state makes sense when, for example, the user has changed the
pass keys. However, it also changes a status quo/master behaviour:
- `g`, change-tab-with-mouse, change-back, `g` -- previously this
scrolled to top; now it does not.
|
|
This reinstates the legacy behaviour in the following case:
- `g`
- change tab
- change back to the original tab
- `g`
- ..... which scrolls to top.
It is not obvious that this is the best behaviour, but it is the legacy
behaviour, and it certainly isn't unreasonable.
|
|
- remove unused "event" parameter
- move methods around to put like with like
- simplify some expressions
- one better method name
|
|
|
|
|
|
|
|
|
|
- simplify pass key condition
- don't keep key-parsing Regexp in memory
- we should reset the key state when the pass keys change
|
|
|
|
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.
|
|
|
|
|
|
Miscellaneous fixes and tweaks, including:
- Reinstate key logging.
- Fix count handling in line with expected behaviour in #2024.
- Remove `noCount` option; we don't need it.
- Simplify logic in various places.
Fixes #2024.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This implements a generic front-end class for key handling (a la normal
mode). Also:
- supports count prefixes (or not)
- supports multi-key mappings (longer than two)
Also included is a very poor-man's demo. See the bottom of
mode_key_handler.coffee for some hard-wired key bindings.
IMPORTANT:
This does not actually work as Vimium. It's just a demo.
|
|
The options page receives messages intended for the background page (and
we're getting console warnings). This is a more general test for when
the front end should ignore such messages.
Fixes #2034.
|
|
A small refactor link hints.
|
