| 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.
|
|
|
|
(Not sure when this crept in.)
We need to ensure that we always generate the same hint strings for the
same filter state. Here, we do this by always using the same mechanism
(@filterLinkHints) to set the hint strings.
|
|
Functionality wise, this is a no-op. However, since we now create a new
LinkHintsMode object on every "f", we don't need to be so careful about
resetting the state on exit.
|
|
|
|
LinkHints.init() isn't doing anything.
|
|
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.
|
|
|
|
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.)
|
|
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 completely decouples settings.coffee from all other background
source files, so that it can (eventually) also be used in the frontend.
|
|
This stops Sync from being referred to from anywhere except
settings.coffee and settings_test.coffee.
|
|
|
|
completion-on-custom-search-only-merge
Conflicts:
background_scripts/completion.coffee
|
|
Fix for #1554.
|
|
|
|
I haven't seen this happen, but...
It could be possible for the iframe's contents to load before this
callback is called (on nextTick), in which case the "load" callback
wouldn't be called. So we delay setting the iframe's source until
nextTick has elapsed.
|
|
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
|
|
If the input is "w ", the user is going for something like "w query
terms" (a custom search engine).
So the domain completer should not offer completions if the user has
finished the first word.
|
|
This makes the behaviour consistent between custom and non-custom
searches when there is no selection in the vomnibar (omni-mode only).
Approach:
- When there is no selection in the vomnibar, we *always* send the
query to to background completer (that is, both for default
searches and for custom searches) and ask the completer to provide
only the primary suggestion. The primary suggestion is just what
you get if you append the query terms to the search URL (default or
custom). We then immediately open the first response.
The round trip for default searches isn't strictly necessary. However,
this uniform approach disentangles some nasty logic in the vomnibar when
we're trying to handle several cases (default or custom search, with or
without prompted text, with or without any suggestions at all). The
extra round trip simplifies the logic to such a great extend that it's
worth it.
|
|
|
|
|
|
This revamps how search-engine configuration is handled, and revises
some rather strange legacy code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixed as per @mrmr1993's comment here:
https://github.com/philc/vimium/commit/1a1b8ec05aaca867261a3556317697d8cdaf7b6c
|
|
This is @mrmr9393's suggestion from #1636. It mimic's Chrome's behaviour
when a javascript: URI is enetered into the omnibox (or clicked).
Fixes #1611.
|
|
|
|
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.
|
|
We should also take a look at these tests and the assumptions they're
making. They're difficult to follow as is.
|
|
|
|
|
|
This reverts commit cfb137d515e6f214322538fdd9a8e236445b63b0.
Conflicts:
content_scripts/vimium_frontend.coffee
There are HUD initialization issues with this.
|
|
The tests are passing, but they are triggering an exception in the
initialization of the HUD. It's proving difficult to get the
initialization in the right order for both the tests and live.
This is a temporary fix...
|
|
This requires passing of an extra truthy argument in order to access the
(generally) unexpected behaviour of sometimes returning the rects of
child elements. All locations in the code that *actually* wanted this
behaviour have been updated to continue using it.
Also add a comment about the unexpected behaviour in the function
description.
|
|
https://github.com/mrmr1993/vimium into mrmr1993-exclusion-rules-pushState-and-hash
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
The event listeners were registered late, potentially allowing the page
to get priority over us for key events, etc., when:
* the original URL was disabled by an exclusion rule
* the URL was changed
- without a page load (by history.pushState or modifying
location.hash), and
- the new URL isn't (completely) disabled by any exclusion rules.
This forces the event listeners to be registered even when the
current URL is disabled, to avoid this problem.
|
|
|
