| Age | Commit message (Collapse) | Author |
|---|
|
Sometimes, link-hints mode fails to launch. See Issue 1 from this post:
https://github.com/philc/vimium/issues/2081#issuecomment-210980903.
Here's a reproducible case:
- visit twitter
- using the vomnibar, visit any other page (in the same tab)
- hit `f` - the link hints fail to load.
What's happening is that the unregister/register frame messages for the
main/top frame arrive in the wrong order (first register, then
unregister). Because these both have the same frame Id, the effect is
that the main/top frame ends up not registered. So there are no
registered frames, so link hints mode doesn't launch.
Only the main/top frame has a re-usable frameId (`0`). All other frames
receive a unique frame Id (which is never re-used).
Here, we just never unregister the main/top frame. That way, it doesn't
matter which order the register/unregister messages arrive in. If the
tab is navigating to a new page, then there'll be a new main/top frame
along soon. If the tab is closing, then we tidy up in the
`chrome.tabs.onRemoved` handler.
|
|
This affects binary search in the history cache.
The returned index can be one beyond the end of array, and so we get an
error when we look it up blindly. So, we need to check.
|
|
I seems that we cannot rely upon either the "unload" event in the
content script or the port's onDisconnect handler there to unregister
frames.
To see this, go to a frame-busy page like this one:
- https://www.theguardian.com/technology/2016/apr/26/apple-iphone-first-revenue-decline-13-years
and then navigate to any other simple page (in the same tab). Navigate
back and forward with `H` and `L`.
If you watch frames registering anf unregistering, almost all of the
frames from the frame-busy page do not unregister.
Here, we unregister frames on onDisconnect in the background page too.
It is possible that this is the source of the problem mentioned as point
1 in this comment:
- https://github.com/philc/vimium/issues/2081#issuecomment-210980903
And for which #2116 is a workaround.
|
|
It reads weird on the helpd dialog if we don't put the full-page and
half-page commands in a similar order.
|
|
- Re-order commands such that we keep like with like, and have the more
important commands nearer the top.
- Re-word some command descriptions such that we use the same words for
the the same thing consistently.
- Move "View Source" to the "Miscellaneous" category.
- Make some commands "advanced commands".
|
|
|
|
It's pretty undiscoverable that you can click command names to yank
them. So, this adds a tip to the bottom of the help dialog.
Also, change the cursor to a pointer when hovering over command names.
|
|
The commands names (in the help dialog) look nicer in italics. They
also format better that way.
|
|
|
|
This needs more work.
|
|
|
|
|
|
Previously, we had two different approaches. This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory. This seems to be the right thing to do. Caching the CSS in
memory consumes a small amount of memory. However, it can only speed up
the fastest loads. It cannot speed up the first load -- which is likely
the one that matters most. So caching the CSS in memory seems to make
little sense.
|
|
This reverts commit 0a49cc45732175c65651b5f054c677d6c42a28c0.
|
|
Previously, we had two different approaches. This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory. This seems to be the right thing to do. Caching the CSS in
memory consumes a small amount of memory. However, it can only speed up
the fastest loads. It cannot speed up the first load -- which is likely
the one that matters most. So caching the CSS in memory seems to make
little sense.
|
|
Replaces #2037.
|
|
|
|
We do not need "displayUrl", we can re-use "shortUrl" instead. It does
what we need already.
|
|
|
|
We only match the text "javascript:...".
The affects only the bookmark completer.
|
|
Show "javascript:" URLs as "javascript:...".
Fixes #961.
|
|
Reinstate test removed incorrectly in d1c230cabb051a5429242c98e67d37b65edc58b8.
|
|
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
|
|
|
