| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Simplify hint string generation
|
|
|
|
When we `simulateSelect` an input and the selection is at the start, we
move it to the end. This works well for single-line inputs. However,
the UX is *bad* for multiline inputs (such as text areas), and doubly so
if the end of the input happens to be out of the viewport.
This commit simply disables the repositioning of the selection within
text areas.
|
|
See #1906.
It is not obvious that this is in fact correct. In particular, it's not
clear how `Ctrl-[` should work on Mac keyboards.
|
|
|
|
Suppress trailing key events (after link hints).
|
|
This ensures that -- on leaving link hints mode -- we consume any trailing keyup events (and don't let the underlying page see them).
Additional notes:
- There are other places where we seem to be leaking keyup events.
- A separate bug... It looks like we're calling `exit()` on link-hints
mode twice.
|
|
Rework to make match counting code for searches more DRY and easier to read
|
|
|
|
|
|
The fix for Chromium issue 483000 landed in this version, so it is no
longer necessary for #1611
|
|
Search completion; add support for Qwant completion
|
|
|
|
Useful for blogs where buttons are named "older posts" and "newer posts".
|
|
|
|
Run on XML pages (version 2)
|
|
1. We're not using Clipboard in the the content scripts, so don't import it.
2. Use consistent syntax for method calls.
This commit is a no-op.
|
|
On a XML view page, createElement will create an "Element" object
Otherwise, createElement('div') will get an object
: HTMLDivElement >> HTMLElement >> Element
|
|
oh my god
|
|
|
|
|
|
|
|
|
|
remove Utils.createElementFromHtml since it's not in use
|
|
This implements @gdh1995's idea from #1796.
|
|
This fixes #1770.
|
|
|
|
|
|
Revert it.
|
|
This fixes two bugs in SimpleCache.
1. Rotate the cache on the next tick. There is a marginally small
chance that the cache will rotate between calls to .has() and .get().
So, we do the rotation ansynchronously. This guarantees that these
two functions will always see the same cache state.
2. The implementation of .clear() (which is unused, I think) has at some
point become out of date (and incorrect) w.r.t. the implementation of
.rotate().
|
|
|
|
|
|
|
|
|
|
(@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.
|
