| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
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.
|
