| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is a simpler version of #1167. It detects clickable elements with
listeners added with `addEventListener()`.
It includes some of @mrmr1993's ideas from #1167 (in fact, it's mostly
those ideas tweaked into a slightly different form).
|
|
|
|
|
|
|
|
|
|
event.keyCode` is depricated:
- https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
|
|
|
|
Move SearchEngines to bg-utils.coffee.
|
|
|
|
|
|
`SearchEngines` was previously in `utils.coffee`, which means it was
loaded in *every* content frame. This is unnecessary, since it is only
used on the background page. So this PR moves it there.
Also:
- Simplify some unnecessarily complex logic in `vomnibar.coffee`.
- Re-use `Utils.parseLines()` to parse the custom search engine configuation text.
|
|
This tweaks the jsaction detection, in particular excluding elements
where the "actionName" is "_". I see a lot of these, and clicking them
doesn't do anything.
Also, added corresponding tests.
|
|
When the implementation of windowIsFocused() changed, the tests started
failing.
(It's not clear how I didn't spot this sooner. I've run the tests
countless times - and they passed - since that change was made.
|
|
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.
|
|
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.
|
|
smblott-github/filtered-hints-better-typed-text-matching
Filtered hints: better typed text handling.
|
|
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.
|
|
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 do not need to install separate event listeners for every callback.
Just install one listener and keep track of the callbacks ourself.
This is clearer, and also determines the order in which callbacks are
called. (Although, we don't rely on that currently.)
This also adds a tests.
|
|
|
|
Which:
- uncovered a typo in 39adee9090fc5aadfd5dd681f91b80025084858a.
Also:
- make Mode.debug a class variable, which is more helpful while trying
to debug. Specifically, you can turn debugging on or off from
within the tests, for example.
|
|
|
|
|
|
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.
|
|
|
|
- Better comments in places.
- Better variable and message names in some places.
|
|
|
|
The question here is where to callapse the selection to, anchor or
focus?
When exiting visual mode, mimic vim. When trasitioning between visual
and caret modes, do what's right to keep the selection in the same
place.
This also adds some related tests.
|
|
This is a better way of stubing for the tests.
Previously, if anything went wrong, there would actually be a visual
effect for the user (the page would scroll). This way, that cannot
happen.
|
|
The coverage here is far from completem but we do catch the basics.
|
|
While working on the visual-mode code, it became apparent that our
current "singleton" implementation is unnecessarily complicated.
This simplifies it. The keys are now required to be strings.
(Previously, they could be any object; which meant we needed to gove
objects an identity. All of which was complicated.)
|
|
- Refactor the three visual-mode modes.
- Use the key-handling framework from #2022.
- Strip some legacy edit-mode code.
- Rename the file (the old file name was misleading).
- Add "aw" and "as", previously we had the code for this from edit mode.
|
|
This previous file name was chosen when we (I) had the intention of
implementing edit mode too.
That initiative has been abandoned, so the file name is inappropriate.
Renaming now in preparation for a significant refactoring of visual
mode.
|
|
We have:
window.XXX = XXX = -> ...
in many places. This commit reduces the number of these, and moves the
exports to the end, where a single comment explains why they're being
exported.
|
|
The front-end initialisation sequence has become quite confused.
This simplifies it, makes things which must be idemtpotent explicit and
renames some functions to make it clear when they run. It also avoids a
situation where we were possibly installing a `domReady` function to
initialise the HUD multiple times.
Should be a no-op functionality wise.
|
|
This tidies up some logic that was showing its age.
|
|
|
|
... they were in the wrong place (and were being run twice).
|
|
This code has been written to test both hints modes, however we were
actually only testing one of them!
|
|
- key handling
- filtered hints - scoring
- filtered hints - tab
- link hints - changing mode
Also, correct the argument ordering in several assert.equal() calls.
|
|
This adds tests for a couple of properties that are required of alphabet
hint strings.
|
|
HUD: Initialize only when the frame receives the focus and Vimium is enabled.
Vomnibar: Initialize in the top frame when Vimium is enabled in *any* frame.
Warning: There may be a race condition here. Specifically, if Vimium
is disabled in the main/top frame (T) but enabled in another frame (A), then the
initialisation could happen in frame A before frame T is listening, so
frame T would miss the initialization message (which is only sent once).
Message listeners are installed early (and probably installed first in
the main/top frame), and the `isEnabledForUrl` messaging takes some
time, so perhaps it's OK. But it *is* a race condition.
Fixes #1838.
|
|
`7gj` should be `1j`.
Also, with:
map ab SOMETHING
`7aab` should be `1ab`.
Replacement for 7774beb6643c0d905f9caba4345453790af948ad.
|
|
With #2022, we can now implement normal-mode key-handling tests.
Writing these tests uncovered the bug behind 7774beb6643c0d905f9caba4345453790af948ad.
|
|
|
|
It makes more sense to pass the passKeys directly to normalMode. So, do
so, and remove the trackState mode option - which isn't otherwise being
used.
|
|
|
|
Previously, the key-handling logic (keyQueue, etc) was and the backend
whereas passKeys were handled in the content scripts - so they were a
long way apart.
Now that they're in the same place, it makes more sense to integrate
passKey handling into the regular key handling, because they depend upon
the same data structures.
|
