| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Consider devicePixelRatio when calculating viewport
|
|
This should fix #2635, fix #2633 and fix #2620.
|
|
Ignore keyboard layout
|
|
|
|
Fix tests: Explicitly select a PhantomJS version for Travis
|
|
|
|
(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.
|
|
|
|
Update URLs to use HTTPS
|
|
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.
|
|
|
|
Firefox: Use options_ui to declare the options page
|
|
Firefox doesn't recognise the "options_page" manifest key, and so isn't
showing a preferences button for Vimium-ff. By moving to "options_ui",
we enable it, and still get the same functionality in Chrome.
|
|
|
|
|
|
|
|
This is a bug-fix release affecting Firefox only.
Accordingly, the Firefox Add-On has been updated, but the Chrome store
version will not be updated.
|
|
|
|
The problem is that Firefox balks at function properties within the
response sent via `postMessage` (whereas Chrome does not).
A concise and safe way to sanitize the response is to convert it to JSON
and back.
Fixes #2576.
|
|
Update README.md
|
|
|
|
|
|
|
|
We were leaking both the `keypress` and the `keyup` events when marks
are created and used.
|
|
Update linear gradient syntax to avoid deprecation
|
|
This updated syntax avoids the following deprecation warning in Chrome Canary v60.0.3090.0:
```[Deprecation] -webkit-gradient is deprecated. Please use linear-gradient or radial-gradient instead.```
This syntax is also supported in Firefox (and [all other modern browsers](https://caniuse.com/#feat=css-gradients)), which could help transitioning the Firefox version, which is in the works.
|
|
FF - Fix "Save Changes" from the exclusions popup
|
|
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.
|
|
Make Mode::exit idempotent
|
|
|
|
|
|
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.
|
