| Age | Commit message (Collapse) | Author |
|---|
|
This puts link hints frame behaviour back to matching
fb00eaa6bd4ee8889d10a9ef9d976fefd3be7879
In particular, we go back to not sending link hints messages to frames
that are too small (according to DomUtils.windowIsTooSmall).
|
|
This is a more complete fix for issue #2125.
|
|
43c7390f987fea063e7a97cd8b37c7b61d45f615 inadvertently broke link hints.
Mention @mrmr1993.
|
|
|
|
|
|
Added UpToDate autocompletion engine
|
|
These are no longer needed following #2601.
@mrmr1993... If these are ever needed again, then we can just revert
this commit (and make them background commands again).
|
|
Tweak of #2601.
|
|
Enable Firefox clipboard commands
|
|
Examples:
# Just create new windows
map X createTab window
map X createTab incognito
# Create windows with URLs
map X createTab window https://developer.chrome.com/home https://github.com/philc/vimium
map X createTab window URL1 URL2 URL3
`2X` creates two new windows, each with all of the indicated URLs.
Fixes #2825.
|
|
|
|
This should have no user-facing impact.
|
|
|
|
|
|
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.
|
