| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This avoids a flicker whereby the keyword is first inserted into the
input, then removed.
|
|
Separate Settings from the background page, and use it directly in options.html/popup.html
|
|
|
|
|
|
|
|
If the page is an XML document, nothing we do works:
* <style> elements show their contents inline,
* <iframe> elements don't load any content,
* document.createElement generates elements that
- have Element.style == null, and
- ignore CSS.
This commit stops us from injecting anything into the DOM from
UIComponent, fixing #1640.
|
|
Instead of directly accessing the background page's Settings object,
the options page and the page popup now have their own.
|
|
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.
|
|
This function does nothing related to Sync, and only affects Settings.
|
|
|
|
Now, a mapping of the form:
map s vomnibar.activate keyword=g
makes the vomnibar open (on "s") with the Google custom-search engine
activated immediately (assuming it's configured).
The corresponding custom search-engine configuration would be:
g: http://www.google.com/search?q=%s Google
|
|
|
|
|
|
Most of this is just a tidy up of code that's been around for a long
time.
The only difference, however, is that now a key mapping can include
extra data ("extras") after the name of the command. For example,
map s vomnibar.activate keyword=g
Here, and extra property "extras" is added to the command registry:
extras: ["keyword=g"]
This is a first step towards direct vomnibar activation for custom
search.
|
|
completion-on-custom-search-only-merge
Conflicts:
background_scripts/completion.coffee
|
|
Fix word movement for non-English characters.
|
|
In omni mode, the vomnibar suggestions are updated asynchronously.
Therefore, the contents of the primary custom search-engine suggestion
may be behind the actual contents of the comnibar input. So, we
reconstruct the custom search-engine query on "enter".
(This fixes a long-standing race condition.)
|
|
This optimisation is now unnecessary, because we will *always* show at
least one completion suggestion in top spot.
|
|
This ensures that <Tab> can always be used to complete the top-ranking
completion.
|
|
This option is no longer needed, since we don't do search completion
except for custom searches.
|
|
|
|
|
|
|
|
Fix for #1554.
|
|
Also suppress highlighting of matching text in previous suggestions.
(It looks odd to have highlighting in some suggestions but not others,
with no apparent difference to the user.)
|
|
Fix incorrect property name from 764d70312f292882abe4940adf9fee3d6e834327.
|
|
Two errors fixed...
|
|
Do not use tab-to-open the vominibar in tabs mode. (It doesn't make any
sense.)
|
|
Go directly to next/previous tab.
|
|
|
|
|
|
This makes nextTab and previousTab go directly to the relevant tab,
without visiting intervening tabs -- all of which avoids a nasty flicker
for 5J or 5K.
|
|
Underling is just ugly, in this case. Also, it is applied
inconsistently between titles and URLs.
|
|
|
|
|
|
|
|
|
|
|
|
Fix UI-Component race condition on start up.
|
|
|
|
smblott-github/change-vomnibar-insert-text-indicator
Change vomnibar insert-text indicator.
|
|
Use a rightwards hooked arrow instead of a small greater-than sign,
which according to @philc, renders as a large greater-than sign on Macs,
See #1651.
|
|
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.
|
|
|
