| Age | Commit message (Collapse) | Author |
|---|
|
Here's the problem...
Many sites define their own keyboard shortcuts, for example Google Play
Music defines `gh` for "go home".
On such sites, it's natural to set up pass keys for `g` and `h`.
But that makes any Vimium key bindings which begin with `g`
inaccessible.
Here, we add a new command `enterNormalMode` which installs a new
normal-mode instance (without any pass keys). This executes a single
normal-mode command then exits.
Example:
map \ enterNormalMode
map | enterNormalMode count=999999
Assuming `g` and `o` are pass keys:
- `gh` or `o` - use the page's binding
- `\gg` - scroll to top
- `2\ggo` - scroll to the top and open the Vomnibar
- `\g<Escape>o` - open the Vomnibar
- `\<Escape>o` - use the page's bindings
- `\\\\\\<Escape>o` - use the page's bindings (new normal-mode instances
displace previous ones)
This required some changes to the scroller. Previously, we only ever
had one normal-mode instance, and could arrange statically that the
scroller's key listeners were above normal-mode's key listeners in the
handler stack. Here, we fix this by adding and removing the scroller's
listeners dynamically, so they're always at the top of the handler
stack.
|
|
This is a no-op. It arranges that the registry entry for each command
is passed to the command, for every command.
That required a small ammount of reworking in a couple of cases.
|
|
Add "mapkey" command for key mappings.
|
|
|
|
When the user begins interacting with one frame, we disable the
grab-back-focus mode in *all* frames.
Previously, grab-back-focus was preventing users from selecting inputs
in frames other than the active frame.
Fixes #2296 (possibly).
|
|
Here, these map to escape:
translate x <c-[>
translate <c-c> <c-[>
|
|
Under *Custom key mappings* (on the options page), this implements:
translate x y
Whenever the users types `x` in normal mode or in visual mode, the `x`
is replaced by `y`.
For example:
map ç l
(which apparently would be helpful on Brazilian keyboards).
Issues:
- Do we want yet another hack like this? This would be documented only on
the wiki.
- If we allowed `translate <c-c> <c-[>` (and extended `isEscape()` to
use the translation), then we'd get the `exitMode` command for free
(#2253).
- Alternatively, instead of adding a new "command" called `translate`,
we could overload the existing `map` command. Since these are
single-key mappings, there's no ambiguity. (Although, I guess there's
a risk some user has junk in their key mappings and would be taken by
surprise).
Inspired by isssue posted by @vhoyer (#2305).
Fixes #2305.
|
|
Comminication by the frame's port is faster, and no response is sent.
|
|
Partially addresses #2303.
|
|
When an <a> spans the end of a line and the start of the next line, we
now highlight both parts of the link (instead of just the first).
Also, refactor code for calculating the position of the viewport into a
separate utility in DomUtils.
|
|
|
|
|
|
Find mode can hang Vimium (fixed).
|
|
"/" followed immediately by "i" can hang Vimium.
The problem is that launching find mode is asynchronous (we wait until
the HUD is available). Because normal mode is still active, we can enter
insert mode *before* the find-mode HUD receives the focus.
The result is that we end up in both find mode and insert mode, the HUD
has the focus, but the HUD is in insert mode, so it ignores keyboard
events (including `Escape`).
The only way out is to click the page's body and then type `Escape`.
This commit demonstrates the problem: 7d2b00411eae3293fa4c7b1f61b384c0c495b5a2.
This happens in practice, for example while a busy page is loading.
This commit fixes this by ensuring that find-mode blocks keyboard events
immediately (and synchronously) on launch.
|
|
Fixes #2273.
Fixes #2281.
This fixes the build with Coffeescript 1.11, so we can remove the
hard-wired dependency and notes.
|
|
Google seems to be using a lot of "title" attributes on buttons. This
makes it possible to type the text in filtered link-hints mode. (And
you can often guess the text; e.g. "close").
We could also show the title text. That is very visually noisy though,
in practice.
|
|
This tweaks the jsaction detection, in particular excluding elements
where the "actionName" is "_". I see a lot of these, and clicking them
doesn't do anything.
Also, added corresponding tests.
|
|
Thinking about it more carefully, this algorithm is always O(n^2).
|
|
Do not set the style on the active hint marker if it's in another frame.
|
|
Applies to filtered hints only.
|
|
The prevents the active element from being reset when we rotate hint
markers.
|
|
When the user selects an active hint with Tab (for filtered hints),
adjust its z-index such at it is top of the stack.
|
|
|
|
|
|
|
|
It is common for link-hint markers to be close togother, and
overlapping.
Here, `<Space>` rotates hint markers such that hidden markers become
visible.
For filtered hints we additionally require a modifier (because `<space>`
on its own is already a token separator).
The calculation of overlapping hints is quite expensive: O(n^2) in the
best case and O(n^3) in the worst cast. The worst case is
extraordinarily unlikely to arise in practice.
|
|
This only affects key mappings of three keys or longer.
Consider:
map goa something
map gob something
Previously, we launched the vomnibar (`o`) on the after `go`, making
these mappings unusable.
This commit fixes that: `go` no longer launches the Vomnibar, but waits
instead to see what the next key is.
|
|
Use prefix matching for global marks.
|
|
|
|
Instead of setting a property of document for `scrollingElement` (if it
is not defined), just use a function and make the decision dynamically
instead.
|
|
This fixes Vimium with the 'Experimental Web Platform Features' flag
enabled, and ensures compatibility across quirks mode scrolling (via
document.body) and standards-compliant scrolling (via
document.documentElement).
|
|
If the user is jumping to a scroll position within a tab, then we need
an exact match on the URL (because otherwise the scroll position doesn't
really have a meaning). Otherwise we only require a prefix match, a la #2250.
|
|
hint a label only if its control is not disabled
|
|
example:
``` html
<label><input type=checkbox disabled />exlpanation</label>
```
|
|
|
|
This reverts commit 2526bb3b0433e5cf645dfd7007ec42860b11ba2a.
See #2164. It seems this is no longer necessary.
|
|
|
|
Due to a typo, VisualLineMode is broken in 1.55.
Fixes #2146.
|
|
If the link's value is not a string, then the previous version of this
fails. The new test will be false for such links.
|
|
adding single left/right angle quotation marks"
This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff.
This reverts #2117.
This breaks next/prev on Reddit (it chooses a different link).
Reddit is an important site, so we should unwind this for now.
Mention @sco-tt.
|
|
Fix UI-component initialization issues (maybe).
|
|
|
|
|
|
next/prev links
|
|
This fixes some UI component initialization issues. It's a long
story...
The problem.
- Go to this page: http://www.thejournal.ie/seanad-election-results-2016-2737768-Apr2016/
- Click one of the links from the "Most Popular" box on the right.
- Navigate back (`H`) and, as the original page is loading, activate the Vomnibar.
In 1.54 this renders Vimium unusable. In `master` this renders the
Vomnibar unsable, but the rest of Vimium usable.
It seems the source of the issue is that we're initializing UI
components too soon. We need to wait until the `readyState` is
"complete".
With this PR:
- The Vomnibar is initialised when the `readyState` is "complete" (in
the top frame only, and only if Vimium is enabled). Requests arriving
prior to then are silently discarded.
- The HUD is also initialized only when the `readyState` is "complete";
however, requests arriving before then are queued. So, if the user
immediately enters insert mode, then the "Insert mode" indicator will
eventually be displayed.
- The help dialog silently discards requests until the `readyState` is
"complete.
I'm posting this as a PR because:
1. It needs some visibility.
2. With this, if the `readyState` *never* reaches "complete", then the
Vomnibar would be unusable. And that's pretty serious.
|
|
There are circumstances when we hav two (identical) vimiumFlash elements
displayed: specifically, when using the waitForEnter keyboard blocker.
So, we should use a class (rather than an id) to style the flash
element.
|
|
left/right angle quotation marks
|
|
Modernize help dialog styling
|
|
On the help dialog, use the same blue of the "Vim" of "Vimium" for
links.
|
|
|
