| Age | Commit message (Collapse) | Author |
|---|
|
The intention is to use this to clean up some of the initialisation
sequences in the front end.
|
|
We can remove these listeners once we're done.
|
|
Miscellaneous fixes and tweaks, including:
- Reinstate key logging.
- Fix count handling in line with expected behaviour in #2024.
- Remove `noCount` option; we don't need it.
- Simplify logic in various places.
Fixes #2024.
|
|
The styles guide says not to use standalone `@`. So this changes the
occurrences I could find (with sed) to `this`. Occurrences within files
with major outstanding PRs are omitted.
|
|
|
|
This stops us from throwing errors when document, window, etc. end up
being passed into DomUtils.isSelectable.
|
|
This fixes #1964.
|
|
This fixes an error in #1950.
There, we need to detect new installs, and did so by checking
`settingsVersion`. However, `settingsVersion` is *always* truthy. So
the "new install" code never triggers. Here, the default value for
`settingsVersion` is falsy.
Note, we *always* set `settingsVersion` when the extension is loaded.
So `settingsVersion` is always set.
|
|
For existing users, the default is "false"; but for new users
wait-for-enter defaults to "true".
|
|
|
|
This affects filtered hints only.
If a hint is triggered because the user typed the link text, then:
- highlight the link
- but wait until the user types `Enter` before activating the link.
|
|
|
|
This allows:
map a passNextKey
map b passNextKey
(Previously, we only picked up the first mapping.)
|
|
Previously, key event parsing was embedded in the normal-mode key
handlers. Here, we move it to a new function (getKeyCharString) in
KeyboardUtils so that it can also be used from elsewhere... In
particular for detecting the pass-next-key key in insertmode.
|
|
We need the key mapped to passNextKey in the front end so that we can
activate pass-next-key from within insert mode too (without the need to
consult the background page).
|
|
|
|
These migrations are at least ten months old (since release).
|
|
|
|
|
|
For Ctrl-[, also require NOT Alt
|
|
|
|
|
|
Simplify hint string generation
|
|
|
|
When we `simulateSelect` an input and the selection is at the start, we
move it to the end. This works well for single-line inputs. However,
the UX is *bad* for multiline inputs (such as text areas), and doubly so
if the end of the input happens to be out of the viewport.
This commit simply disables the repositioning of the selection within
text areas.
|
|
See #1906.
It is not obvious that this is in fact correct. In particular, it's not
clear how `Ctrl-[` should work on Mac keyboards.
|
|
|
|
Suppress trailing key events (after link hints).
|
|
This ensures that -- on leaving link hints mode -- we consume any trailing keyup events (and don't let the underlying page see them).
Additional notes:
- There are other places where we seem to be leaking keyup events.
- A separate bug... It looks like we're calling `exit()` on link-hints
mode twice.
|
|
Rework to make match counting code for searches more DRY and easier to read
|
|
|
|
|
|
The fix for Chromium issue 483000 landed in this version, so it is no
longer necessary for #1611
|
|
Search completion; add support for Qwant completion
|
|
|
|
Useful for blogs where buttons are named "older posts" and "newer posts".
|
|
|
|
Run on XML pages (version 2)
|
|
1. We're not using Clipboard in the the content scripts, so don't import it.
2. Use consistent syntax for method calls.
This commit is a no-op.
|
|
On a XML view page, createElement will create an "Element" object
Otherwise, createElement('div') will get an object
: HTMLDivElement >> HTMLElement >> Element
|
|
oh my god
|
|
|
|
|
|
|
|
|
|
remove Utils.createElementFromHtml since it's not in use
|
|
This implements @gdh1995's idea from #1796.
|
|
This fixes #1770.
|
|
|
|
|
