| Age | Commit message (Collapse) | Author | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
Previously, we had two different approaches.  This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory.  This seems to be the right thing to do.  Caching the CSS in
memory consumes a small amount of memory.  However, it can only speed up
the fastest loads.  It cannot speed up the first load -- which is likely
the one that matters most.  So caching the CSS in memory seems to make
little sense.
 | 
 | 
This uses image data (instead of a path) for the page icon.  It also
only builds 19x19 and 38x38 icons, as per the
chrome.browserAction.setIcon() documentation.
This appears to fix a memory leak related to a recent Chrome regression
(versions 49+).
Fixes #2055.
 | 
 | 
 | 
 | 
 | 
 | 
This tweaks @mrmr1993's logging ideas discussed in #1629:
- Do not generate log entries from the logging page itself.
- Use the logger for *all* logging (including from `commands.coffee`, and from `bgLog`).
@mrmr1993's original idea is 91fb337c9d92f6291ef42c55c4d29ca35b710203.
 | 
 | 
The fix for Chromium issue 483000 landed in this version, so it is no
longer necessary for #1611
 | 
 | 
 | 
 | 
This prevents issues like #1731 and is an (better) alternative to #1732.
 | 
 | 
(@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.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
This is @mrmr1993's work from #1041.
Reload content scripts when vimium is installed or updates.
(@mrmr1993:  The automatic merge was really messy (or, at least, I
couldn't figure out what was going on).  Since the bulk of #1041 was
actually quite compact, I took the liberty of just copying it in.  Hope
you don't mind.)
 | 
 | 
 | 
 | 
As a proof of concept, this incorporates normal mode, passkeys mode and
insert mode.
 | 
 | 
- Simplify component API.
- Iframe flashes on re-focus.
- Probably some other stuff which I've forgotten.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 |