| Age | Commit message (Collapse) | Author | 
|---|
|  |  | 
|  | 1. Explicitly remove comments.
2. A trailing backslash means the current line continues on the next line.
E.g.
    a \
      b \
      c
is a single line `a b c`.
This helps alleviate the fact that configuration lines can be very long,
whereas the *Custom key mappings* input is quite narrow.
TODO: We should use the same line parser in the custom-search-engines
input. | 
|  |  | 
|  | Under *Custom key mappings* (on the options page), this implements:
    translate x y
Whenever the users types `x` in normal mode or in visual mode, the `x`
is replaced by `y`.
For example:
    map ç l
(which apparently would be helpful on Brazilian keyboards).
Issues:
- Do we want yet another hack like this?  This would be documented only on
  the wiki.
- If we allowed `translate <c-c> <c-[>` (and extended `isEscape()` to
  use the translation), then we'd get the `exitMode` command for free
  (#2253).
- Alternatively, instead of adding a new "command" called `translate`,
  we could overload the existing `map` command.  Since these are
  single-key mappings, there's no ambiguity.  (Although, I guess there's
  a risk some user has junk in their key mappings and would be taken by
  surprise).
Inspired by isssue posted by @vhoyer (#2305).
Fixes #2305. | 
|  | Comminication by the frame's port is faster, and no response is sent. | 
|  | We do not need the registryEntry's decription in the content scripts, so
remove it (saving a marginal amount of memory and time). | 
|  | Fixes #2299.
Also, separate this regexp out into its constituent parts, because it is
becoming too different to read. | 
|  |  | 
|  | Enable silent/patch releases. | 
|  |  | 
|  |  | 
|  | The new name better describes which the function does. | 
|  |  | 
|  | This reworks the parsing of key sequences like `<c-a-Z>x`:
Advantages over the status quo:
- Parses key sequences in one only place (previously two),
- Removes two hideous regular expression.
- Admits multi-modifier bindings (like `<c-a-Z>`).
- Adds more (and better) tests.
- (And it should be easier to maintain.)
Replaces #2210 (this also simplifies key parsing substantially). | 
|  | Currently, all new releases trigger a notification.
This changes that behaviour such that if the previous and current
releases have the same major and minor release numbers, then no
notification is shown.
This allows us to push bug-fix and minor releases without bugging the
user. | 
|  | This adds advanced options for toggleMuteTab.
Examples:
   map X toggleMuteTab all
   map Y toggleMuteTab other
In the first case, all audible, unmuted tabs are muted; otherwise all
muted tabs are unmuted.
The second case is the same, except that the current tab is excluded
from consideration.
Follow on from #2269. | 
|  | Use prefix matching for global marks. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | If the user is jumping to a scroll position within a tab, then we need
an exact match on the URL (because otherwise the scroll position doesn't
really have a meaning).  Otherwise we only require a prefix match, a la #2250. | 
|  | This changes the logic for selecting an existing tab when using global marks.
Previously, an exact RUL match was required.  Here, we only require a prefix match.
For example, if the global-mark URL is:
    https://inbox.google.com/u/0/
Then a tab with the URL
    https://inbox.google.com/u/0/sent
will be selected.
This is a more usable approach when the user uses global marks to visit
important sites like gmail, Facebook or Twitter.  On these sites, the
URL changes, but the user still thinks of the tab as their "gmail tab",
for example.
Also, when choosing between multiple candidate tabs:
- If there is at least one candidate in the current window, then only consider candidates in the current window.
- If there are more than one candidates, then don't select the current tab.
- Finally, select the remaining candidate with the shortest URL.
Closes #2248. | 
|  | Chrome stop using <backspace> to go back, but some still wants this
feature.
This should fix #2207 and #2214. | 
|  |  | 
|  |  | 
|  | Sometimes, link-hints mode fails to launch.  See Issue 1 from this post:
https://github.com/philc/vimium/issues/2081#issuecomment-210980903.
Here's a reproducible case:
- visit twitter
- using the vomnibar, visit any other page (in the same tab)
- hit `f` - the link hints fail to load.
What's happening is that the unregister/register frame messages for the
main/top frame arrive in the wrong order (first register, then
unregister).  Because these both have the same frame Id, the effect is
that the main/top frame ends up not registered.  So there are no
registered frames, so link hints mode doesn't launch.
Only the main/top frame has a re-usable frameId (`0`).  All other frames
receive a unique frame Id (which is never re-used).
Here, we just never unregister the main/top frame.  That way, it doesn't
matter which order the register/unregister messages arrive in.  If the
tab is navigating to a new page, then there'll be a new main/top frame
along soon.  If the tab is closing, then we tidy up in the
`chrome.tabs.onRemoved` handler. | 
|  | This affects binary search in the history cache.
The returned index can be one beyond the end of array, and so we get an
error when we look it up blindly.  So, we need to check. | 
|  | I seems that we cannot rely upon either the "unload" event in the
content script or the port's onDisconnect handler there to unregister
frames.
To see this, go to a frame-busy page like this one:
- https://www.theguardian.com/technology/2016/apr/26/apple-iphone-first-revenue-decline-13-years
and then navigate to any other simple page (in the same tab).  Navigate
back and forward with `H` and `L`.
If you watch frames registering anf unregistering, almost all of the
frames from the frame-busy page do not unregister.
Here, we unregister frames on onDisconnect in the background page too.
It is possible that this is the source of the problem mentioned as point
1 in this comment:
- https://github.com/philc/vimium/issues/2081#issuecomment-210980903
And for which #2116 is a workaround. | 
|  | It reads weird on the helpd dialog if we don't put the full-page and
half-page commands in a similar order. | 
|  | - Re-order commands such that we keep like with like, and have the more
  important commands nearer the top.
- Re-word some command descriptions such that we use the same words for
  the the same thing consistently.
- Move "View Source" to the "Miscellaneous" category.
- Make some commands "advanced commands". | 
|  |  | 
|  | It's pretty undiscoverable that you can click command names to yank
them.  So, this adds a tip to the bottom of the help dialog.
Also, change the cursor to a pointer when hovering over command names. | 
|  | The commands names (in the help dialog) look nicer in italics.  They
also format better that way. | 
|  |  | 
|  | This needs more work. | 
|  |  | 
|  |  | 
|  | Previously, we had two different approaches.  This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory.  This seems to be the right thing to do.  Caching the CSS in
memory consumes a small amount of memory.  However, it can only speed up
the fastest loads.  It cannot speed up the first load -- which is likely
the one that matters most.  So caching the CSS in memory seems to make
little sense. | 
|  | This reverts commit 0a49cc45732175c65651b5f054c677d6c42a28c0. | 
|  | Previously, we had two different approaches.  This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory.  This seems to be the right thing to do.  Caching the CSS in
memory consumes a small amount of memory.  However, it can only speed up
the fastest loads.  It cannot speed up the first load -- which is likely
the one that matters most.  So caching the CSS in memory seems to make
little sense. | 
|  | Replaces #2037. | 
|  |  | 
|  | We do not need "displayUrl", we can re-use "shortUrl" instead.  It does
what we need already. | 
|  |  | 
|  | We only match the text "javascript:...".
The affects only the bookmark completer. | 
|  | Show "javascript:" URLs as "javascript:...".
Fixes #961. | 
|  | Reinstate test removed incorrectly in d1c230cabb051a5429242c98e67d37b65edc58b8. |