| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This is a workaround for Firefox bug 1408996.
|
|
|
|
In particular, these are used in the current (2017-10-19) version of
YouTube. This fixes #2730.
|
|
Some tweaks to #2701 from @ahstro.
1. Simplify the logic for calculating `modifiers`.
2. Revert the ordering of the `event.repeat` test and `keyChar` assignment.
3. Link hint characters *only* match in upper case.
4. If there are link-hint characters (non numbers), then shifted characters are only ever hints.
5. Otherwise, revert to doing all hint text comparison in lower case.
|
|
|
|
Injecting HTML into XML documents on Firefox breaks the rendering
(collapsing it into plain text). By not loading it until explicitly
requested, we can avoid this breakage (at least, until a user triggers
some of our UI manually).
|
|
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
|
