| Age | Commit message (Collapse) | Author |
|---|
|
The check that an element as an href (for certain hint modes) can be
done earlier, thereby avoid the need to pass that information between
frames.
|
|
We take a copy of the frame Ids and ports at the point which link-hints
mode is launched, and use that subsequently. Therefore, a newly created
frame cannot cause the hint coordinator to become confused.
Also: add debugging code.
|
|
There's no need for the previous complicated approach to UI component
initialialisation, in particular for the Vomnibar.
We only initialise the Vomnibar in the top frame. However, if for some
reason it hasn't been initialised by the time it's needed, then we can
just initialise it then. We are only initialising it early to avoid
flicker, so it's not a correctness issue. And the only reason it
wouldn't be initialised is if Vimium is disabled in the top frame, but
enabled in some other frame -- which is not a common case.
|
|
This affects focusFrame and link hints.
We do not register tiny frames. The reason for doing this is that link
hints messages all (registered) frames to collect their hint
descriptors. On some sites (e.g. Google Inbox and other Google
properties), there are many tiny iframes (on the order of 12 or 15 or
so). Those frames cannot provide useful hints, so -- by not registering
them -- we don't ask them for hints.
The intention is to speed up the link-hints activation sequence.
|
|
This is a no-op.
It separates the process of registering a frame with the background page
from the port initialization. The idea is that -- soon -- we will only
register some frames; in particular, we should not register the many
tiny iframes on pages like GMail.
The eventual goal is to speed up the global link-hints initialisation
sequence.
|
|
|
|
This seems to be considerably faster than using sendMessage().
|
|
Without considering the size of the data passed, ports seem to be about
5 times fast than sendMessage(), so we use ports of link-hint messages
wherever possible.
|
|
We use portsForTab[0] instead.
|
|
This maintains a mapping from tab Ids to a mapping from frame Ids to
their ports.
|
|
This uses image data (instead of a path) for the page icon. It also
only builds 19x19 and 38x38 icons, as per the
chrome.browserAction.setIcon() documentation.
This appears to fix a memory leak related to a recent Chrome regression
(versions 49+).
Fixes #2055.
|
|
- Better comments in places.
- Better variable and message names in some places.
|
|
We cannot use "request" and "name" to describe a link-hints message.
The message is then accepted (and fails) on the options page where there
is no handler.
So, here, use "messageType" instead of "name".
|
|
TODO:
- fix tests
|
|
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).
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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 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`.
|
