| Age | Commit message (Collapse) | Author |
|---|
|
TODO:
- fix tests
|
|
There were two problems, both stemming from the fact that the
notification was being displayed in the top frame, even if the mark was
triggered in another frame:
1. That looks odd, because we close the HUD in one frame then open it in
another.
2. As a side effect, we were moving the focus to the top frame.
Here, we work out what's going to happen before sending the message to
the background page. This allows us to display the message in the HUD
in the frame which generated it.
|
|
|
|
Some of this code is showing its age, so these are just a number of
minor tweaks (to keep things clear, consistent and concise).
Also, add a couple of tests (while we're at it).
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
|
|
This command (LinkHints.activateModeToCopyLinkUrl) has been in the wrong
spot for quite some time. This just moves it to be with the other
link-hints commands.
|
|
We pass the count to *all* front-end commands. All of the commands
which don't use a count, just ignore it.
|
|
With this change, now *every* front-end command either accepts a count
argument, or or it doesn't accept a count at all.
|
|
"description" is the first element here, not all elements. So
"descriptor" is a better name.
|
|
|
|
|
|
|
|
In #2053, I omitted to notice that the top-frame (vomnibar)
initialisation sequence also generates O(n^2) messages.
This makes that sequence O(n).
|
|
The frame Ids are sufficiently distinct. And we do not always have
enough horizontal space to keep log messages on a single line.
|
|
|
|
... we know what day it is!
|
|
|
|
|
|
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`.
|
|
|
|
|
