| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
We only need showLinkText in the hint's local frame, so do not transmit
it to remote frames.
|
|
The "reason" a hint is available is only ever needed in the hint's own
frame, so there's no need to pass it to other frames.
|
|
Previously, we passed each hints rect to every other frame. However,
the rect is only actually needed in its own frame.
Here, we instead keep (and use) each hint's rect locally only.
|
|
Previously, we were rendering hints in all frames, but displaying only
in their own frame
With n frames and m hints, we rendered n*m hints.
With this, hints are only rendered in their own frame, so we only render
m hints.
|
|
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.
|
|
This fixes an error in 39adee9090fc5aadfd5dd681f91b80025084858a.
Specifically, if there are no hints to select from, or no
documentElement, then link-hints mode exits without initiating an actual
mode (i.e. without calling its super() constructor).
With 39adee9090fc5aadfd5dd681f91b80025084858a, that leaves a mode in
place which blocks all keyboard events, thereby rendering Vimium
entirely hung.
See this line:
https://github.com/philc/vimium/commit/39adee9090fc5aadfd5dd681f91b80025084858a#diff-e9abcb9ebcdb5af8e9f33651364673a1R59.
Here:
- we explicitly remove the keyboard-blocking mode
- we add exitOnEscape (so that the situation is at least
recoverable), and
- we add an indicator (so that we can see what's going on).
It is proposed that the indicator is a temporary feature, while the
global link hints feature is in shake down.
|
|
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.
|
|
We need to wait for documentReady() here to ensure that the document is ready in the top frame.
|
|
I've not observed this, but it could possily happen...
If the stableSortCount gets out of sync in different frames, then
different frames might make different decisions about the ordering of
the hints.
Ti avoid this potentially happening, we initialise the stableSortCount
every time link-hints mode is activated.
|
|
Previously, we could select divs, uls, and ols for scrolling, but we
couldn't get back to scrolling the document body.
This makes it possible to select document.body for scrolling.
Unfortunately, sometimes the hint appears in a rather odd place (because
it's "on top of" something else which is clickable.
|
|
There seems to be an issue on this page:
- http://i.imgur.com/PdmUjij.jpg
whereby "DOMContentLoaded" isn't firing. The page structure is unusual
(involving a shadow-DOM element), which might be the source of the
problem.
What happens is that the "DOMContentLoaded" event fires as required, but
the document state is still "loading".
Here, we just say that if the "DOMContentLoaded" handler has fired
once, then we're good to go.
|
|
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.
|
|
The reason for doing this is that we will be using the same test to
decide whether or not to register a frame.
|
|
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.
|
|
If document.documentElement isn't ready, then we can'r generate hints.
Moreover, this would crash -- thereby hanging global link hints.
|
|
|
|
Following on from f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125, I omitted to
verify that the height of the dialog was correct on taller screens.
|
|
With global link hints, hints might be launched in one frame when the
settings are not yet loaded in another. This could lead to one frame
using one settings value, and another another value. (Because we use
the default value if the settings are not yet loaded.) And this in turn
could cause link hints to crash if filetered hints are used (because, in
that case, we would not calculate hint.linkText in one frame, but then
try to use that value later in another frame).
|
