| Age | Commit message (Collapse) | Author |
|
See #1722.
When Settings.get("linkHintCharacters") is its default value, this
preserves the legacy behaviour of using the keyChar from keydown events
for link-hint matching. This admits users using either Latin or
non-Latin characters for link hints.
|
|
I think we can safely remove this comment now, @mrmr1993. This is
working out very nicely.
|
|
|
|
|
|
Exit on click because, if the user is clicking stuff, then they're
probably no longer interested in selecting links.
Exit on scroll because, if the user is scrolling, then the link hints
can all go out of the viewport.
|
|
On some keyboards (who knows?) "`" or "'" could be shift keys. In this
case, with the previous implementation, these would be treated as global
marks and `` would be unusable. This commit fixes that problem.
|
|
With global marks, we may later create a new tab when the mark is used.
When doing so, we should always be using the URL and scroll position of
the top frame within the tab. For example, if a global mark is created
from within the Hangouts frame of Google's Inbox and the mark is later
used, then we should create a new tab for Inbox's URL and scroll
position, not for the Hangout's URL and scroll position.
|
|
|
|
This should make link hints usable on non-Latin keyboards (e.g. Russian
keyboards).
Fixes #1387. (Maybe - because it's not clear from the discussion there
exactly what users want.)
|
|
|
|
As suggested by @mrmr1993 in #1716.
|
|
As suggested by @mrmr1993 in #1716.
|
|
On sites with several frames (e.g. Facebook), if we allow all of the
frames to handle the setScrollPosition and showHudForDuration messages,
then the focus ends up in an arbitrary frame. And, on Facebook, say,
Vimium ends up broken until the focus is returned to the main frame.
So, we only handle these messages in the main frame.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... which is weird, because the tests are passing here. Let's see what
Travis makes of this.
|
|
It's pretty common that we want to suppress all keyboard events, so
let's support that in modes.coffee, thereby simplifying handlers
elsewhere.
|
|
Fixes #1712:
- Make global marks work.
- Add mode indicator.
- Don't fail for global marks on background page if mark is not set.
- Give HUD warning for global marks if global mark is not set.
(The diff is big but, which the exception of infrastructure refactoring,
the main change is to not exit on <Shift>, thereby fixing #1712).
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"setIcon" should be in the list of messages delivered to the options
page (and for which there is no handler).
|
|
Direct keyboard access to custom-search engines via keyword flag
|
|
Add a link to the wiki on the help page.
|
|
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.
|
|
Ass suggested in by @LarryBattle in #1643.
|
|
"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.)
|
|
This avoids a flicker whereby the keyword is first inserted into the
input, then removed.
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
Fix word movement for non-English characters.
|
|
|