| Age | Commit message (Collapse) | Author |
|---|
|
When distributing hint descriptors, do not post a frame's own hint
descriptors back to the frame itself. It already has them.
With regard to the message-passing cost only, this represents a speedup
of approximately 3/2 for link-busy sites like reddit -- several tens of
milliseconds for me. There are other costs too (such as processing the
hint descriptors) bu these are not affected.
|
|
|
|
|
|
- Unregister frames with the background-page hint coordinator.
- Better page cleanup in the content scripts.
- Require documentReady before harvesting hints.
There is still an issue in some cases when link-hints are activated as a
page is transitioning, but that problem case seems to have existed in
1.54. I'll continue to investigate.
|
|
It seems we cannot rely on the port being disconnected to unregister a
frame. So we need to unregister it on "unload".
|
|
There's other stuff (ports, frameIds) in @tabState[tabId] that we don't
need in the front end. Here, we only send the three properties which we
do need.
|
|
This is not at all satisfactory.
I've seen cases where global link hints hangs, apparently because we do
not hear back from a frame. The issue is repeatable when it happens,
but not repeatable in general (if you reload the page, then it goes
away). This suggests that there may be something fundamentally wrong
with the global link-hints logic. However, what?
In the interim, this adds a timer to trigger link-hints mode activation
with whataver hints we do have after a short period of time.
Ideally, we'll be able to get rid of this soon.
|
|
If we lose contact with a frame (it's goine away) while still awaiting
hints from that frame, then post a dummy/empty list of hints instead.
This seems very unlikely to come up, but we should guard against it
anyway.
We use "nextTick()" so that we finish sending the current message
before sending the dummy hints.
|
|
This is experimental, and may be reverted.
I suspect that the special treatment of the top frame may actually be
causing problems for global link hints (rather than solving them!).
|
|
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
|
|
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.
|
