| Age | Commit message (Collapse) | Author |
|---|
|
There's no need for the setting of the icon to be driven from the
content script. We first know the enabled state in the background page,
so set the icon there immediately.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The intention is to move checkIfEnabledForUrl to the frames port. That
needs to run pre domReady, so first -- here -- we separate the two
ports.
|
|
We treat the top frame specially (because it always has a frameId of 0).
See point "Two" in this comment:
- https://github.com/philc/vimium/pull/2053#issuecomment-196707223
|
|
We never unregister the main/top frame. If the tab is navigating to
another page, then there'll be a new top frame (with the same Id) along
soon. If the tab is closing, then we'll tidy up in the
chrome.tabs.onRemoved listener, below. This approach avoids a
dependency on the order in which register and unregister events happens.
See comment in #2053.
|
|
Tweaks, plus... Reinstate deletion of two cache entries on tab close.
|
|
|
|
Use `onConnect()`, the `domReady` port and `onDisconnect()` to track
the frames within a tab.
|
|
Oversight from #2022.
|
|
This generalises the mechanism by which commands are always run in the
tab's main/top frame. Currently, that's just the Vomnibar.
This is a precursor to moving other UI components to the main/top frame.
It should be fairly trivial to move the help page to the main frame.
The HUD might be trickier.
Mention: @mrmr1993.
|
|
If we just use the name `background` instead of `isBackgroundCommand`,
then we can simplify the building of registry entries.
This is preparitory to adding a new registryEntry field: topFrame;
initially just for the Vomnibar, but thereafter for other UI components.
|
|
|
|
|
|
|
|
- simplify pass key condition
- don't keep key-parsing Regexp in memory
- we should reset the key state when the pass keys change
|
|
|
|
|
|
|
|
|
|
... We need it for the help page.
|
|
|
|
- There's no need to keep `@keyToCommandRegistry`; it's regenerated
whenever it's needed.
|
|
With:
map g something
map gg somethingElse
The mapping for "g" always takes priority, regardless of the order in
which they're encountered in `@keyToCommandRegistry`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The default (for when no options are provided) is of the wrong type.
This works as is, but should really be fixed -- as here.
|
|
Pass to count to scroll commands.
|
|
Currently, `10j` keeping `j` held down scrolls quickly for a time then
reduces back the regular hold-`j` scroll speed. Therefore, the user
cannot use a count to influence the smooth-scrolling scroll speed.
This PR fixes that by passing the count to the scroll functions.
Consequently, we adjust the actual scroll amount (which affects the
scroll speed) rather than calling the scroll commands several times
(which doesn't).
|
|
This implements a poor-man's build info.
See #1352. Unfortunately, that requires a separate build target, and
does not work with `cake autobuild`.
This just records the *install date* and displays that info on the
logging page. "Install date" because we can reliably determine it, and
because it does answer the question *have I upgrade Vimium on this
machine since last week?*. And on the logging page because that's out
of the way, and not part of the regular Vimium interface.
|
|
We need to multiply by `count=N` *before* checking `repeatLimit`.
Tweaks #2001.
|
|
With #2006 and #2009, this is no longer being used.
|
|
Remove (unused) `tabInfoMap`.
|
|
Conflicts:
background_scripts/commands.coffee
|
|
Fix `<count>removeTab`.
|
|
Previously:
map J scrollDown count=NotANumber
would break the command completely.
Fixes an error introduced in #2001.
|
|
Specifically, avoid reliance on `chrome.tabs.onSelectionChanged`.
If we merge this and #2006, then we can delete all of the
`chrome.tabs.onSelectionChanged` code.
|
|
|
|
|
|
We were incorrectly setting `options.count` to `NaN` if there was no
command option.
|
|
This fix the problem that `chrome.tabs.onActivated` won't be triggered
when we switch Chrome windows.
|
