| Age | Commit message (Collapse) | Author |
|---|
|
This is a workaround for Firefox bug 1408996.
|
|
If
map <c-[> someCommand
is configured, then the hardwired `<c-[>` meaning `Escape` behaviour is disabled.
Users who want to map `<c-[>` probably *never* use it as `Escape`.
Fixes #2722.
|
|
Inject user css into all frames
|
|
Use openerTabId in chrome.tabs.create when possible
|
|
|
|
|
|
|
|
|
|
Recognise URLs like:
- moz-extension://c66906b4-3785-4a60-97bc-094a6366017e/pages/options.html
Fixes #2657.
|
|
|
|
|
|
Mention @mrmr1993.
Mention @gdh1995.
We have zoom issues resulting from:
- style
- zoom
- --force-device-scale-factor=1.5
- HiDPI
This intended to fix HiDPI, but seems to have created problems in the
some of the other cases.
I don't have time to figure out the problem right now, so I'm going to
revert this and push it as 1.60.2.
That leaves us pretty much where we were before, I think, in terms of
zoom.
We can come back to it later.
|
|
|
|
|
|
This also stops the content scripts from being injected into each frame
on reload (in Firefox only). They do not successfully connect to the
background page, and it causes considerable lag, so we lose nothing by
doing this.
|
|
This should fix #2635, fix #2633 and fix #2620.
|
|
Ignore keyboard layout
|
|
(Similar to idea suggested by @mrmr1993.)
This way:
- we do not have to replicate the stub code, and
- we have minimal impact on the live implementation.
|
|
Check whether events are trusted before executing listeners
|
|
This fixes the tests for #2626.
Note: This may not be th best approach.
The problem is that, for the first time, we're using `Settings` (and
hence `chrome.storage`) within the Vomnibar and HUD iframes, and our
`chrome` stubs are not injected into those frames.
Mention @mrmr1993. Matt: Do you know of a better approach? Can we
inject the stubs programmatically in the tests? An alternative approach
would be appreciated.
|
|
|
|
See this comment:
https://github.com/philc/vimium/pull/2626#issuecomment-326553282.
|
|
|
|
|
|
Fixes #2618.
|
|
|
|
Updating URLs to use HTTPS provides greater privacy and reduces the
potential of having content modified whilst in transit (as it happening
more and more by ISPs, networks, state actors etc).
These URLs themselves have been tested and confirmed to work over HTTPS.
|
|
|
|
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.
|
|
@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 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.
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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.
|
|
getViewportTopLeft: support zoomed static documentElement
|
