| Age | Commit message (Collapse) | Author | 
|---|
|  | While looking into #2841, I observed that we are seeing keyboard events
for which neither `event.key` not `event.code` is defined.  They might
be being generated by the page. | 
|  | Enable Firefox clipboard commands | 
|  | This adds support for pasting rich text from the clipboard | 
|  |  | 
|  | This restores the old behaviour prior to
c4cc76e9f6a0a99ebc297e420be739a0fc77f827 (PR #2772). | 
|  |  | 
|  |  | 
|  | The tests make more sense in this order. | 
|  | This allows any special key to mapped, simply by using the `event.key`
key name. E.g.
   map <enter> scrollDown
Replaces #2770.
Fixes #2769. | 
|  | Credit to @gdh1995 for catching these oversights. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Move normal mode and its commands out of vimium_frontend.coffee | 
|  |  | 
|  | See the *very* bottom of the options page (below advanced settings).
Clicking "Backup" creates a JSON file.
Selecting a backup populates the options inputs, the user then clicks *Save Changes* to confirm. | 
|  | 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. | 
|  |  |