The help page gets pretty lopsided when advanced commands are shown. This balances things out a bit by creating a new category for Vomnibar commands in the right-hand column.
On smaller screens (and with the advanced options unfolded), the help page can need scrolling. Currently, you have to click it to give it the focus. Here, we simulate-click it, so that "j" and "k" scrolling is active immediately.
"Flags" implies binary toggles. The term "options" seems more consistent with what's actually going on here.
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.)
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.
…stom-search-only-merge Conflicts: background_scripts/completion.coffee