| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
Improve firefox support
|
|
Regenerate help page data when key bindings are updated
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This does NOT fix wrapping, only catches errors
|
|
|
|
|
|
|
|
This reverts commit d00345f45b5b3e56970237799c69808527e91919.
This is not (and will not be) supported by Firefox.
|
|
|
|
|
|
Show line breaks for newlines in the options page (FF)
|
|
For textareas, we still want line breaks, otherwise we would use an
input. Chrome (incorrectly) renders newlines in `white-space: nowrap`
as line breaks; however, firefox collapses the newlines into horizontal
whitespace.
`white-space: pre` is spec'd as intended, and works correctly in Chrome
and FF.
|
