| Age | Commit message (Collapse) | Author | 
|---|
|  |  | 
|  |  | 
|  | If `event.code` is not defined, then fall back to using `event.key`
instead.
Fixes #3099. | 
|  | Fixes #3068. | 
|  | Fixed frustrating IME leftover issue when press ESC in input | 
|  | replace \xA0 on copying and pasting | 
|  | Fix Firefox link hints. | 
|  | This was failing in iframes in Firefox (causing all sorts of other stuff
to fail). | 
|  |  | 
|  | Fixes #2958 (probably).
This appears to be correct for target "_blank" (or not) and modifiers
(or not).  That's four cases.
It will be *incorrect* if there is a click listener on a target "_blank"
link.  Some conditions are tested to try to prevent that from happening.
This only affects Firefox.  Chrome is unaffected. | 
|  | Fixes #2860.  That issue reports that, when the target is "_blank",
Firefox/Vimium ends up opening two tabs. | 
|  | 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. |