| Age | Commit message (Collapse) | Author |
|---|
|
Firefox: Use options_ui to declare the options page
|
|
Firefox doesn't recognise the "options_page" manifest key, and so isn't
showing a preferences button for Vimium-ff. By moving to "options_ui",
we enable it, and still get the same functionality in Chrome.
|
|
|
|
|
|
|
|
This is a bug-fix release affecting Firefox only.
Accordingly, the Firefox Add-On has been updated, but the Chrome store
version will not be updated.
|
|
|
|
The problem is that Firefox balks at function properties within the
response sent via `postMessage` (whereas Chrome does not).
A concise and safe way to sanitize the response is to convert it to JSON
and back.
Fixes #2576.
|
|
Update README.md
|
|
|
|
|
|
|
|
We were leaking both the `keypress` and the `keyup` events when marks
are created and used.
|
|
Update linear gradient syntax to avoid deprecation
|
|
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.
|
|
FF - Fix "Save Changes" from the exclusions popup
|
|
This stops |Exclusions| from holding a reference to the |value|
parameter passed to |Settings.set|. In Firefox, this object is garbage
collected when the owning context (the exclusions popup) is closed.
The fix for all such cases in the future is to switch to using
|Settings.get|, which implicitly does |JSON.parse JSON.stringify value|
and thus returns an object in the same context as |Settings|.
We could fix this generally by doing this for the
|Settings.performPostUpdateHook| call in |Settings.set| instead.
However, I'm not convinced that it warrants the overhead of a
|JSON.parse| for every |Settings.set| call.
|
|
Make Mode::exit idempotent
|
|
|
|
|
|
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.
|
|
@mrmr1993... This puts the logic of how we choose the selection type in
one place; so, if you have a better idea of how to determine the
selection type, then we just change it here. Once.
|
|
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.
|
|
This is the filtered-hints feature whereby links aren't activiated until
the user hits `Enter`.
There was a race condition caused by forcing this setting to true for
new users *before* the correct storage area was determined in
`Settings.init()`.
Mention @mrmr1993.
|
|
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.
|
|
Firefox baulks at "about:newtab" in createTab (but seems happy with no
URL specified). Chrome is also happy with no URL specified.
(Does this mean that we don't need "about:newtab" ANYWHERE in the code
base? Could Settings.defaults.newTabUrl just be ""?)
Mention @mrmr1993.
|
|
We were leaking the keydown event to the page when using TAB to select
link hints (filtered hints).
|
|
@mrmr1993: This is trivial fix for Firefox, so it doesn't warrant a PR.
I'll mention you just to keep you up to date on commits like this,
though.
|
|
Fix gF (mainFrame) command on Firefox
|
|
This works around FF issue 554039, which prevents window.top.focus()
from working.
|
|
Firefox: some history entries have no title.
|
|
This causes `o`/`O` to crash (producing no suggestions).
As a workaround, set any such title to "".
|
|
|
|
|
|
Rework key handling to keydown
|
|
|
|
|
|
Error was introduced by seemingly innocuous but nevertheless significant
change in previous commit.
Tests picked up the problem.
|
|
That is, allow at most one handler to be installed at any one time.
I have not observed this to be necessary. However, if there were any
systematic way in which we weren't seeing the necessary keyup events,
then these handlers would just be added and added. So this seems safer.
|
|
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
|
|
|
|
|
|
|
|
Keyboard repeats were interfering with smooth scrolling. But we should
be ignoreing them anyway.
|
|
event.keyCode` is depricated:
- https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
|
|
|
|
|
|
|
