| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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 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.
|
|
The Settings object used by the background page now uses 1 of 3 caches,
depending on the context it is available in:
* localStorage - in the background page
* a copy of localStorage - in non-background extension pages
(options.html, popup.html, etc.)
* an empty object - in all other pages (where localStorage doesn't point
to the extension's localStorage object).
For any extension page which is *not* the background page, a copy of
localStorage is used instead of true localStorage:
* Once localStorage is updated by one background page, the others can
only see the updated copy.
- Pages with an updated cache can't tell which changes are new, and so
don't know which postUpdateHooks to run.
* By copying localStorage's contents into a new object, extension pages
can still access settings synchronously.
- This is especially important to options.html and popup.html; they
will not work without it.
|
|
|
|
This stops Sync from being referred to from anywhere except
settings.coffee and settings_test.coffee.
|
|
|
|
This revamps how search-engine configuration is handled, and revises
some rather strange legacy code.
|
|
|
|
|
|
|
|
The name "SearchEngineCompleter" is more appropriate for completions
actually delivered by a search engine. Also, what was
SearchEngineCompleter is usually referred to as "custom search engines"
elsewhere.
|
|
This logic should never have been in settings.coffee. This moves it to completion.coffee, where it belongs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This avoids the need to continually re-parse the strings each time we
load the option value.
|
|
|
