| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Previously, we were transferring a "transferable event" from the HUD UI
component to the content script (when find mode exits).
In addition to being unnecessary, this was triggering a warning in the
console because we were reading *all* of the events keys, including one
which triggers a "this is being deprecated" warning.
The approach here is simpler, transfers less data and avoids triggering
the warning.
|
|
If the help dialog loses the focus and closes, then we abandon any HUD
which is being displayed. This ensures that - when the help dialog is
reopenned - we're not displaying an old, out-of-date HUD message.
|
|
Previously, requests (like opening the Vomnibar) would be silently
discarded if they arrive before the document is ready. Here, we queue
them instead.
|
|
This replaces c01d7eea8675f9a7d84999777e8de72244d687b6.
All UI components require the document to be ready. So, here the
constructor waits for DomUtils.documentReady(). The diff looks big, but
mainly it's a result of changes in indentation in the constructor and in
hide().
Also, hide() now uses @postMessage() to post a null message. This
forces hide to use @iframePort.use(), which ensures that hide()s cannot
overtake activate()s.
This continues #2100.
|
|
This reverts commit c01d7eea8675f9a7d84999777e8de72244d687b6.
Preparatory to implementing an alternative approach.
|
|
|
|
The Vomnibar isn't needed on most tabs, so don't init it.
I cannot detect any sluggishness as a result of this.
|
|
This avoids initializing around 15 (almost all unused) HUDs on sites
like GMail and Google inbox.
Because the HUD is small, there is not noticable flicker.
|
|
Replaces #2037.
|
|
|
|
In 5c3e4bda2968486e23f8cc3410e776de67fec849, I omitted to observe that
we need to know whether the window has the focus *before* the DOM is
ready when checking whether Vimium is enabled.
This fixes that.
|
|
This fixes two issues:
- We cannot set windowHasFocus until the DOM is ready (because
document.hasFocus isn't set until then.
- We should use windowhasFocus in prefernce to document.hasFocus
because, for framesets, document.hasFocus is true for both the
frameset and a focused contained frame.
|
|
|
|
Remove special-purpose code from `gf`.
Instead, register the help dialog frame when it launches, and unregister
it when it's hidden.
This way, when the helpd-dialog frame is hidden, it simply isn't
available for `gf` and for link hints.
|
|
|
|
When the help dialog UI component has been created but subsequently
hidden, `gf` was nevertheless selecting it.
|
|
|
|
|
|
It interferes with the HUD's timing.
|
|
|
|
The code to handle the focus for UI components has been tweaked and
adapted over time, and has become quite complicated (and brittle). This
reworks it from scratch, and co-locates similar code which does related
things.
Fixes #2099.
|
|
Rework UI component init sequence.
|
|
In testing global link hints, it seems that UI components can be opened
before they're actually ready, and Vimium hangs with a broken UI
component displayed. This issue seems to be in 1.54 too.
It's not clear what's causing this -- and it's hard to reproduce
systematically. However, it only seems to happen on navigation.
Therefore, it seems likely that there is an issue with the
initialization sequence.
Here, we wait for:
- the DOM content to be ready, and
- the port to be provided
before registering the UI component as ready.
|
|
Fixes #2092.
|
|
Similarly to the previous commit: 454f5272c71388c53665d7505aa6832566284e2b.
This is intended to mitigate some CSP violations we're seeing. In some
circumstances - as yet not fully pinned down - messages to the HUD
trigger CSP violations. Until we track that down, we move all HUD
operations (in link hints) to the end of their execution slice. So, if
HUD operations fail, then they won't affect any other operation.
The error message for offending HUD operations is:
ui_component.js:55:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided
('chrome-extension://hiihfcebjbnoniicphblpiekhfmbdmog') does not match
the recipient window's origin ('null').
|
|
This is part of an effort (as yet incomplete) to track down some CSP
violations we're getting, in this case related to global link hints.
Prior to this, we were seeing CSP violations when accessing the window
subsequently to collecting the hints, specifically when accessing
window.scrollX/Y. Here, we collect the window position immediately,
when initially harvesting the hints.
|
|
Assume there is an existing range selection.
Consider `v`, `Escape`. Previously, this had the side effect of
clearing the selection. That behaviour seems odd and wrong.
Here, we retain the selection if there was an existing range selection
when visual mode was launched.
Arguably, this removes a "feature" whereby `v`, `Escape` clears the
selection. Here, we take it that the oddity above outweighs the loss of
this arguably unintentional "feature".
|
|
Here's the trade off... We either *always* initialize the help dialog in
every frame of every tab, or we initialize it only when needed.
The help dialog is rarely used by anybody except beginners, so the
latter seems like the better approach. However, on busy/slow loading
pages, the help dialog can fail to load on page start up. (We need to
fix this, but I don't know how right now). In the meantime, the better
compromise seems to be to initialize the help dialog only when needed.
This was the status quo prior to 6e12e005a4261711583571be23018481a4a23230
and 09e119db8d8c3ad2077ac509f73fefb76a08fac0.
|
|
|
|
On a slow loading page, as the page is loading, hit `o` repeatedly.
Eventually, Vimium hangs.
We seem to have had this problem for quite some time (e.g. it's in
1.54).
This fixes the problem by ensuring that the Vomnibar is initialized
before launching it.
Also fix the same issue for the help dialog.
|
|
1. Do not initialize UI components until the DOm is ready.
2. Do not register UI components as ready (specifically the HUD) until
the full initialization sequence is complete.
This goes some way towards fixing the issue described in this comment:
https://github.com/philc/vimium/issues/2081#issuecomment-205758102
It relates to link-hints mode hanging when launched during a navigation.
This problem exists in 1.54, but emerged during testing of global link
hints.
"Some way toeards fixing..." because it is still possible to trigger
issues.
|
|
Two minor tweaks:
1. Do not use ".indexOf()" three times for each comparison; do it just
once.
2. Check the common case (no match) first.
These are very minor performance tweaks; but, with global link hints,
we pay this cost n times (for n frames).
|
|
There's no need to repeatedly trim linkText. Instead, just trim it when
it's first collected, then we can assume from there on that it's
trimmed.
|
|
There is no point accepting characters which are used for splitting the
link text in the query string, since such characters cannot appear in
link text words.
|
|
- Reduce the number of passes over hint markers from two to one.
- Filter out non-matching hints before sorting.
- Do not trim the search string twice.
|
|
smblott-github/filtered-hints-better-typed-text-matching
Filtered hints: better typed text handling.
|
|
Previously this had two independent functions: set the @mode and update
the indicator. We don't always do those two things at the same time.
So this refactors things into two separate functions.
|
|
|
|
When the user is typing a link's text, any mistyped character exits link
hints mode. This makes little sense. In practice, this usually happens
because the user mis-typed something.
Here, we ignore typed characters which do not match any hints.
(Also, add a test for this.)
|
|
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".
|
|
|
|
|
|
When a link's text is particularly long, displaying all of its text
makes the hint look weird - so shorten it.
We still use the full text for matching.
|
|
Scrollable divs are offered via link hints. It makes no sense to offer
the current activated element for selection - so don't.
On a "normal" page where there's just one scrollable thing,
document.body, this means that we no longer offer the unnecessary
"Scroll." hint.
|
|
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.
|
