| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes #2642.
|
|
|
|
|
|
We were leaking both the `keypress` and the `keyup` events when marks
are created and used.
|
|
This updated syntax avoids the following deprecation warning in Chrome Canary v60.0.3090.0:
```[Deprecation] -webkit-gradient is deprecated. Please use linear-gradient or radial-gradient instead.```
This syntax is also supported in Firefox (and [all other modern browsers](https://caniuse.com/#feat=css-gradients)), which could help transitioning the Firefox version, which is in the works.
|
|
|
|
This is a follow up to the move to using keydown for all events, and
fixes a bug I introduced.
Specifically, we were reacting to the first keydown event, which could
be just the `Shift` key.
|
|
This is a no-op. It is preparatory to implementing a suitable polyfill
for `selection.type` for Firefox.
|
|
This reverts commit 50b117733c4f0ecf9fd507c28d2f2967b5b1404b.
Reverting this. In response to comments from @mrmr1993, this is not the
best way of achieving what's required.
|
|
The problem with visual mode is that `@selection.type` isn't implemented
in Firefox/Gecko. Here, we simulate the same effect with `anchorNode`
and the length of the selection.
Mention @mrmr1993.
|
|
We were leaking the keydown event to the page when using TAB to select
link hints (filtered hints).
|
|
This works around FF issue 554039, which prevents window.top.focus()
from working.
|
|
Error was introduced by seemingly innocuous but nevertheless significant
change in previous commit.
Tests picked up the problem.
|
|
For filtered link hints, " " was broken; it was treated as "space".
|
|
This avoids the possibility of leaking keyup events if the keys a
released in a different order from that in which they were pressed.
Also, replace suppressKeyupAfterEscape with this same mechanism.
This fixes a bug (in master/1.59) whereby we leak the keyup event for
`i` when entering insert mode.
TODO:
- `/`, `<Escape>` leaks a keyup event
- `i` leaks a keyup event
|
|
|
|
|
|
|
|
event.keyCode` is depricated:
- https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This does NOT fix wrapping, only catches errors
|
|
|
|
|
|
1. Remove the use of mapKeyRegistery from the mode handler.
2. Refactor use of mapKeyRegistery keyboard utils.
This is preparatory to refactoring all of the keyboard handling.
|
|
|
|
|
|
InsertMode should not handle key events if document.body is editable
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
