| Age | Commit message (Collapse) | Author |
|---|
|
If
map <c-[> someCommand
is configured, then the hardwired `<c-[>` meaning `Escape` behaviour is disabled.
Users who want to map `<c-[>` probably *never* use it as `Escape`.
Fixes #2722.
|
|
|
|
|
|
Search completion; add support for Google.co.jp completion
|
|
Inject user css into all frames
|
|
This fixes #2594.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also stops the content scripts from being injected into each frame
on reload (in Firefox only). They do not successfully connect to the
background page, and it causes considerable lag, so we lose nothing by
doing this.
|
|
Updating URLs to use HTTPS provides greater privacy and reduces the
potential of having content modified whilst in transit (as it happening
more and more by ISPs, networks, state actors etc).
These URLs themselves have been tested and confirmed to work over HTTPS.
|
|
The problem is that Firefox balks at function properties within the
response sent via `postMessage` (whereas Chrome does not).
A concise and safe way to sanitize the response is to convert it to JSON
and back.
Fixes #2576.
|
|
This stops |Exclusions| from holding a reference to the |value|
parameter passed to |Settings.set|. In Firefox, this object is garbage
collected when the owning context (the exclusions popup) is closed.
The fix for all such cases in the future is to switch to using
|Settings.get|, which implicitly does |JSON.parse JSON.stringify value|
and thus returns an object in the same context as |Settings|.
We could fix this generally by doing this for the
|Settings.performPostUpdateHook| call in |Settings.set| instead.
However, I'm not convinced that it warrants the overhead of a
|JSON.parse| for every |Settings.set| call.
|
|
Firefox baulks at "about:newtab" in createTab (but seems happy with no
URL specified). Chrome is also happy with no URL specified.
(Does this mean that we don't need "about:newtab" ANYWHERE in the code
base? Could Settings.defaults.newTabUrl just be ""?)
Mention @mrmr1993.
|
|
This causes `o`/`O` to crash (producing no suggestions).
As a workaround, set any such title to "".
|
|
Improve firefox support
|
|
|
|
|
|
|
|
The documentation suggests that 'highlighted' is equivalent to
'selected'. However, multiple tabs can be highlighted in a window -- in
fact, everywhere 'selected' was used, we wanted the unique active tab.
|
|
|
|
|
|
|
|
|
|
This means that we get the new tabs in the same order as they are
specified in the key mapping.
|
|
Example:
map a createTab http://edition.cnn.com/ http://www.bbc.co.uk/news
which creates two new tabs, but preloaded with these specific URLs.
`2a` creates four new tabs, two copies of each.
Limitation:
- We cannot control the order of the tabs, so we might get CNN then BBC,
or BBC then CNN. This happens because command options are stored in
an object, and we cannot control the order of the keys.
Also, with:
map a createTab http://www.bbc.co.uk/news http://www.bbc.co.uk/news
we only get one new tab (same reason as above).
|
|
Keep the option list (in addition to the parsed command options) because
some commands may depend upon the command option order. One currect
example is #2318.
|
|
(Because we're scanning backwards throught the mappings, we shouldn't
overwrite an existing mapping.)
|
|
|
|
Previously, the dynamic HTML for the help dialog was generated on the
background page. The HTML itself was tangled in with program logic.
Here, we move all of the HTML to HTML5 templates; also, we build the
help-dialog contents in the help dialog itself, not on the background
page.
Note: #2368 is included here too.
(Background: I'm trying to clean up some of the command and help-dialog
logic in preparation for addressing the issue of how to document command
options, see #2319.)
|
|
There are two changes here:
1. Treat built-in key mappings and custom key mappings in the same way;
that is, we prepend the built-in mappings to the custom mappings and
then parse them all together. This results in a number of
simplifications due to previous duplication of logic and the elimination
of special cases.
2. Parse key mappings in reverse order, so we can just ignore key
mappings after first encountering a key sequence. So, `map`, `unmap`
and `unmapAll` are all treated in more or less the same way.
This is preparatory to reworking some aspects of the help page. In
particular, regardless of the order of maps, unmaps, etc., this approach
makes it easier to find the mapping in effect for a key sequence (and be
able to recreate the order of those mappings).
|
|
`SearchEngines` was previously in `utils.coffee`, which means it was
loaded in *every* content frame. This is unnecessary, since it is only
used on the background page. So this PR moves it there.
Also:
- Simplify some unnecessarily complex logic in `vomnibar.coffee`.
- Re-use `Utils.parseLines()` to parse the custom search engine configuation text.
|
|
|
|
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.
|
