| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
For example, the host JavaScript may create an "about:blank" iframe with a
`content-editable` `body`, and then:
* the parent frame may handle `Escape` key events by itself
* but now, Vimium always grabs `Escape` events
* and tries to exit `InsertMode`
* although `document.body` is still current `activeElement`
after `body.blur()`
* as a result, neither the parent can receive and handle wanted keyevents,
nor Vimium will succeed in returing back to NormalMode
|
|
Steps to reproduce:
- Press and hold `j`.
- Tab `k`.
- Release `j`.
The tap on `k` is uninstalling the `cancelEventListener` installed by
`j`, and because we advance `@time`, the `j` stops scrolling and
removes the `cancelEventListener` installed for `k`. So we end up with
no `cancelEventListener` installed.
The fix is to make the `cancelEventListener` specific to the scroller
instance.
The more fundamental problem here is that we're mixing dynamic and
static state. A better approach would be to have `CoreScroller` as a
class, with a new instance created for each scroll instance.
|
|
Example page: http://codeforces.com/contest/752/problem/B.
There, `element.tagName` is an element with `name` `tagName` (not a string). Here, we guard against that case.
Fixes #2305.
|
|
Try the following....
- load page
- `/`
- type some junk which matches nothing
- `Escape`
We expect to leave find mode. Instead, we have to hit escape again to
get out of find mode.
Here, `focusNode.focus()` is not a function.
|
|
|
|
New command option to enter normal mode
|
|
Makes sure all custom link hint characters defined in settings are lowercase
|
|
In a browser, I find global marks considerably more useful than local
marks; for example, I use marks to quickly jump back to my email tab.
Unfortunately, inheriting vim's approach, global marks require capital
letters, so the `<Shift>` key.
This PR implements:
map m Marks.activateCreateMode swap
map ' Marks.activateGotoMode swap
which inverts the `isGlobalMark()` test for the `<Shift>` key.
Is the name `swap` the best one? It could be `invert` instead, or
perhaps there's something better.
|
|
|
|
Previously, the dynamic HTML for the help dialog was generated on the
background page. The HTML itself was tangled in with program logic.
Here, we move all of the HTML to HTML5 templates; also, we build the
help-dialog contents in the help dialog itself, not on the background
page.
Note: #2368 is included here too.
(Background: I'm trying to clean up some of the command and help-dialog
logic in preparation for addressing the issue of how to document command
options, see #2319.)
|
|
Move SearchEngines to bg-utils.coffee.
|
|
|
|
|
|
case when link hints are generated
|
|
`SearchEngines` was previously in `utils.coffee`, which means it was
loaded in *every* content frame. This is unnecessary, since it is only
used on the background page. So this PR moves it there.
Also:
- Simplify some unnecessarily complex logic in `vomnibar.coffee`.
- Re-use `Utils.parseLines()` to parse the custom search engine configuation text.
|
|
|
|
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.
|
