| Age | Commit message (Collapse) | Author |
|---|
|
This was failing in iframes in Firefox (causing all sorts of other stuff
to fail).
|
|
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.
|
|
(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.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adding single left/right angle quotation marks"
This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff.
This reverts #2117.
This breaks next/prev on Reddit (it chooses a different link).
Reddit is an important site, so we should unwind this for now.
Mention @sco-tt.
|
|
left/right angle quotation marks
|
|
Settings.onLoaded() is similar to Settings.use(), except it does not
require/expect a key argument.
Would could simulate .onLoaded() with .use() by artificially adding an
(unused) key, but that would make the code less clear. So it seems
better to have a separate method.
|
|
This fixes an error in #1950.
There, we need to detect new installs, and did so by checking
`settingsVersion`. However, `settingsVersion` is *always* truthy. So
the "new install" code never triggers. Here, the default value for
`settingsVersion` is falsy.
Note, we *always* set `settingsVersion` when the extension is loaded.
So `settingsVersion` is always set.
|
|
For existing users, the default is "false"; but for new users
wait-for-enter defaults to "true".
|
|
|
|
This affects filtered hints only.
If a hint is triggered because the user typed the link text, then:
- highlight the link
- but wait until the user types `Enter` before activating the link.
|
|
This allows:
map a passNextKey
map b passNextKey
(Previously, we only picked up the first mapping.)
|
|
We need the key mapped to passNextKey in the front end so that we can
activate pass-next-key from within insert mode too (without the need to
consult the background page).
|
|
These migrations are at least ten months old (since release).
|
|
|
|
|
|
Search completion; add support for Qwant completion
|
|
|
|
Useful for blogs where buttons are named "older posts" and "newer posts".
|
|
|
|
|
|
|
|
|
|
|
|
(@mrmr1993: This is yet another approach to the Settings problem.)
With the new Settings implemetation, settings which have a non-default
value and which are not in synced storage (that is, they have not been
changed since synced storage was introduced) are not currently
accessible to content scripts. This commit makes such settings
accessible via chrome.storage.local.
Important:
- There's a change to the established settings data model here.
Previously, settings with default values were not stored; here, they
are. This eliminates a considerable amount logic from Settings, but
means that migrations will be required if default values are changed
in future. (Other than type changes, have we ever changed a default
value?)
- There's also a change (bug fix?) to the behaviour when an affected
setting is reset to its default value. Previously, the change would
*not* have been synced (whereas all other changes are). Here, such
changes *are* synced. The previous behaviour was inconsistent with
the syncing behaviour of all other options changes.
Note:
- This isn't particularly well tested. It's being committed mainly just
for consideration of the approach, initially.
|
|
|
|
Because we haven't had a default value for this setting, we never sync
it, which means -- when its not at its default value -- it isn't picked
up in content scripts by the new settings system.
Fixes #1731.
|
|
|
|
|
|
|
|
(This bug has been around for quite some time. I just noticed it now.)
|
|
|
|
|
|
|
|
This is a minor re-working of #1705 from @mrmr1993.
The main changes are:
- Simplify initialisation logic.
- Always initialise Settings immediately and automatically (ie. don't
initialise Settings separately and manually in the background,
content scripts, options and tests).
- Get rid of addEventListener (it's only being used for on "load").
- Add Settings.use() in its place.
|
|
We need this because Settings rejects key/value pairs from
chrome.storage for which there were no default values.
Previously, this only meant that the setting would not sync; now it
meant that the setting wasn't ever made available to the frontend. This
commit fixes it, and now the setting will sync.
|
|
|
|
|
|
|
