| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Always use keydown and event.key (partial PDF-tab fix)
|
|
|
|
Fixes #2454.
Because `Utils` wasn't available, neither were the `mapkey` mappings.
|
|
- For PDF tabs, we see keydown events but we don't see the corresponding
keypress events, so this allows us to navigate through PDF tabs with
J/K.
- This relies on using `event.key` instead of `event.keyIdentifier`
(which is no longer supported).
- Also move mapkey handling into the keyboard utils.
The effect of all of this is to simplify and unify much of our key
handling.
Fixes #1243 (for tab commands).
There are known places where we can prune a considerable amount of key
handling code. However, that code is left in place for now in case this
change throws up some unexpected issues.
|
|
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.
|
|
|
|
Fixes #2453.
|
|
Minor fix: Use the appropriate handler for hashChange
|
|
|
|
|
|
|
|
fix typo
|
|
|
|
|
|
getViewportTopLeft: support zoomed static documentElement
|
|
InsertMode should not handle key events if document.body is editable
|
|
Use event argument instead of global event object
|
|
|
|
|
|
Replace depreciated APIs
|
|
|
|
The documentation suggests that 'highlighted' is equivalent to
'selected'. However, multiple tabs can be highlighted in a window -- in
fact, everywhere 'selected' was used, we wanted the unique active tab.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
If an element's `contain` is/contains `paint`, then it will be forced
showing just as its `position` is `relative`.
|
|
if `document.documentElement` is zoomed, Vimium's hints `<div>` are also zoomed,
and then `scrollY` may be not equal with viewport client rect's `top`.
Example:
* make the tab zoom level is 1, `documentElement`'s `zoom` style is 2
* open a page, scroll to the top left corner
* press `f`, and all things are right
* exit LinkHints mode, scroll down for 100px, and then press `f`
* this time all hints has moved down 200px from the correct place
|
|
Fix (another) infinite-scroll issue.
|
|
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.
|
|
Guard against element.tagName not being a string.
|
|
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.
|
|
|
|
|
|
Don't set the update_url by default.
|
|
Add match-about-blank permission.
|
|
New command option to enter normal mode
|
|
Makes sure all custom link hint characters defined in settings are lowercase
|
|
This allows Vimium to run in iframes with `about:blank` URLs.
Fixes #2360.
|
|
|
|
|
|
|
|
Float find-mode matches to the right.
|
