| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
Direct keyboard access to custom-search engines via keyword flag
|
|
For ...
map s Vomnibar.activate keyword=g
... we verify that "g" is indeed a custom search-engine keyword before
setting it. If it is not, we output a console.log message and launch a
vanilla vomnibar. (An alternative would be to bail.)
|
|
This will allow us to use the same search-engine parsing code in the
background page and in content scripts.
|
|
|
|
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.
|
|
|
|
|
|
Fix for #1554.
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
A custom search engine like this...
i: https://www.google.ie/search?q=%s&num=30&newwindow=1&biw=1918&bih=1015&tbm=isch Google image search
Should not match a URL like this...
https://www.google.ie/search?q=bbc+sport
|
|
|
