| Age | Commit message (Collapse) | Author |
|---|
|
Modernize help dialog styling
|
|
Make zoomable images clickable: e.g. http://i.imgur.com/LdCeLlk.jpg/.
|
|
Re-order the tests such that we don't even do the scoring if there are
no query (search) terms.
This might (very) marginally speed up link-hints launch.
|
|
Following 029741ea2d93031f0c9d5e57ba9cf75546976798 (which seemed
trivial), I forgot to check the tests (which were in fact broken, and
correctly broken).
If there is no link-text key queue, then *all* links should match.
|
|
Only keep non-empty link words. Empty link words cannot be matched, and
leading empty link words disrupt the scoring of matches at the start of
the text.
E.g. "9 new messages" with a query "new" should score as a match at the
start of the text.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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).
|
|
Problems:
- The meanings of some of the Mode/handlerStack constant names is far
from obvious.
- The same thing is named different things in different places.
This changes various constant names such that:
- the names used in the handler stack and in the modes are the same.
- ditto vis-a-vis DomUtils.
Also, break out the core of the handler stacks' `bubbleEvent` method
into a switch statements. This makes it more obvious that the cases are
mutually exclusive.
|
|
Because there is a small amount of time between link-hints mode being
requested and it being activated, it was possible to launch other Vimium
commands (e.g. the Vomnibar) after requesting link-hints mode, and
before link-hints mode starts.
This prevents that.
|
|
The exit sequence is clearer like this.
|
|
|
|
Context: filtered link hints with wait-for-enter enabled. Once a link
is selected, it is highlighted. We then consume all keyboard events
until the user hits enter, at which point the link is activated.
Problem: When we're waiting, the link is highlighted. It looks to the
user like `Escape` should cancel.
This implements escape to cancel at that point in the exit sequence.
|
|
|
|
hintMarkers was previously passed around (within the link-hints mode
class) from function to function. With #2048 (global link hints), it is
better if this becomes @hintMarkers (that is, is available directly to
all methods within the class.
With #2048, we used bind to avoid having to do this - to keep the diff
clearer. Here, we do it directly.
|
|
These variable names are misleading. The things being manipulated are
actually hint descriptors.
So this renames the variables accordingly.
|
|
This code (LocalHints) has been embedded into the middle of the
link-hints mode class. And it shouldn't be.
This moves it out, and allows us to unwind some of the gymnastics #2048
(global link hints) introduced to avoid having an incomprehensible diff.
|
|
Testing the `scrollHeight` is cheaper than testing scrollability. There
are a lot of non-scrollabile divs, so it makes sense to use this cheaper
test as a filter.
|
|
We should start by checking the *parent* of the candidate descendant.
|
|
We recognise elements with a class names containing the text "button" as
clickable. However, often they're not, they're just wrapping a
clickable thing, like a real button.
Here, we filter out such false positives.
This has two effects:
- It eliminates quite a number of real false pasitives in practice.
- With fewer hints close together, fewer hint markers are obscured by
the hints from (non-clickable) wrappers. This reduces the need for
rotating the hint stacking order, e.g #1252.
|
|
Fixes #425.
Conflicts:
content_scripts/scroller.coffee
|
