| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
New command option to enter normal mode
|
|
`SearchEngines` was previously in `utils.coffee`, which means it was
loaded in *every* content frame. This is unnecessary, since it is only
used on the background page. So this PR moves it there.
Also:
- Simplify some unnecessarily complex logic in `vomnibar.coffee`.
- Re-use `Utils.parseLines()` to parse the custom search engine configuation text.
|
|
Here's the problem...
Many sites define their own keyboard shortcuts, for example Google Play
Music defines `gh` for "go home".
On such sites, it's natural to set up pass keys for `g` and `h`.
But that makes any Vimium key bindings which begin with `g`
inaccessible.
Here, we add a new command `enterNormalMode` which installs a new
normal-mode instance (without any pass keys). This executes a single
normal-mode command then exits.
Example:
map \ enterNormalMode
map | enterNormalMode count=999999
Assuming `g` and `o` are pass keys:
- `gh` or `o` - use the page's binding
- `\gg` - scroll to top
- `2\ggo` - scroll to the top and open the Vomnibar
- `\g<Escape>o` - open the Vomnibar
- `\<Escape>o` - use the page's bindings
- `\\\\\\<Escape>o` - use the page's bindings (new normal-mode instances
displace previous ones)
This required some changes to the scroller. Previously, we only ever
had one normal-mode instance, and could arrange statically that the
scroller's key listeners were above normal-mode's key listeners in the
handler stack. Here, we fix this by adding and removing the scroller's
listeners dynamically, so they're always at the top of the handler
stack.
|
|
|
|
|
|
|
|
Here, these map to escape:
translate x <c-[>
translate <c-c> <c-[>
|
|
When an <a> spans the end of a line and the start of the next line, we
now highlight both parts of the link (instead of just the first).
Also, refactor code for calculating the position of the viewport into a
separate utility in DomUtils.
|
|
This reworks the parsing of key sequences like `<c-a-Z>x`:
Advantages over the status quo:
- Parses key sequences in one only place (previously two),
- Removes two hideous regular expression.
- Admits multi-modifier bindings (like `<c-a-Z>`).
- Adds more (and better) tests.
- (And it should be easier to maintain.)
Replaces #2210 (this also simplifies key parsing substantially).
|
|
|
|
It is common for link-hint markers to be close togother, and
overlapping.
Here, `<Space>` rotates hint markers such that hidden markers become
visible.
For filtered hints we additionally require a modifier (because `<space>`
on its own is already a token separator).
The calculation of overlapping hints is quite expensive: O(n^2) in the
best case and O(n^3) in the worst cast. The worst case is
extraordinarily unlikely to arise in practice.
|
|
|
|
|
|
|
|
|
|
Chrome stop using <backspace> to go back, but some still wants this
feature.
This should fix #2207 and #2214.
|
|
The char `\xA0` may be contained in a string if we use `y` to yank a line
which contains ` `.
|
|
see https://github.com/philc/vimium/issues/986#issuecomment-53955175
|
