| Age | Commit message (Collapse) | Author |
|---|
|
|
|
... Also, do not set an active hint marker initially (because it's not
predicatble which hint will be selected).
|
|
Here's why:
- b7535a604954b5873d825eb66bfecd08f1f2c99b is complicated and complex (O(n^2)).
- With experience, it is not obviously better than what was there
before, and in some cases it's worse.
- b7535a604954b5873d825eb66bfecd08f1f2c99b selects way too much text in
some cases; e.g. on Google Inbox, it selects text lengths in the tens
of thousands of characters. That cannot be useful.
- With global hints, this extra cost (resulting from passing large
objects between frames) is significant and noticable.
- The simpler approach of accounting for text length when scoring
filtered hints (tweaked here: 5cbc5ad702a01a81b98f8c82edb3b6d227c2c7b5)
works better in practice.
|
|
Just tweaks.
|
|
- Better comments in places.
- Better variable and message names in some places.
|
|
|
|
Because we're running hint modes in multiple frames, we need to ensure
the right frame has the focus for selectable elements (inputs).
|
|
|
|
Here's the issue (and we may have to address this ouside of this PR).
If we put the HUD in the top frame, then the top frame grabs the focus
when the HUD is displayed.
If we open link hints with the help dialog open, then the help dialog
loses the focus, and we can't `Esc` out of it.
|
|
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
|
|
This moves the link activation logic out of LinkHintsMode and into the
hint coordinator.
At this point, there is (almost) no DOM-specific logic left in
LinksHintMode. It only depends an a list of "elements", each of which
has a rect property.
The main exception to this is filtered hints. In the following commits,
we're going to leave filtered hints behind - mainly to keep the diff
shorter and cleaner.
|
|
This adds a shim between launching a link-hints mode and creating the
LinkHintsMode object. The shim is responsibly for for finding the
clickable elements. This is preparatory to implementing global hints.
|
|
Really, all of the code related to finding clickable elements is
unrelated to LinkHintsMode. Unfortunately, it's embedded in the middle
of the class. So, we can't use it from outside of the class.
This is a temporary restructuring of the link-hints code. The intention
is to move the lines around eventually. For now, however, we do it like
this to keep the diff smaller and clearer.
|
|
In the previous commits, I omitted to actually check that the help
dialog wasn't closing on the options page.
I should be good now.
|
|
The help-dialog UI component was ignoring requests to "hide" when other
frames are focused (because previously it covered the whole screen, and
no other frame could get the focus).
With f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125, the help dialog no longer
covers the whole screen, so it must listen for and react to
"frameFocused" events.
However, the help dialog should not "hide" when the frame that is
focused is itself! This required a little extra plumbing. That
plumbing is helpful, though, because it allows individual UI components
to decide what to do when another frame receives the focus (as opposed
to the previious version, which simply unilaterally sent a "hide"
message).
|
|
This allows the user to enter key mappings on the options page with the
help dialog open.
Fixes #2045.
|
|
We've consumed the event here, so we should suppress it.
|
|
With the help dialog in an iframe, Escape no longer closes it if that
iframe loses the focus. This fixes that.
See point 2 of #2045.
This is not a perfect solution: it only works if the focus ends up in
the frame from which the help dialog was launched. However, that is the
the common case and, in particular, it is the case which arises on the
options page -- which is a particularly important use case.
|
|
With several frames, only one frame can call sendResponse(), whichever
one happens to call it first.
getScrollPosition, is the only handler for which we care about the
response. Here, we make sure that sendResponse() will *only* be called
in the top frame - where we want it called.
This fixes a possible race condition in global marks.
Additionally, although it's not the primary intention here, this also
avoids calling sendResponse() unnecessarily in cases where we don't use
the response.
|
|
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.
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
Perform background commands on the requesting tab (v2)
|
|
There's no need to have the previous unusual calling style (passing the
arguments as a list. It looks more natural to pass tham just as regular
arguments, as here.
|
|
We pass the count to *all* front-end commands. All of the commands
which don't use a count, just ignore it.
|
|
|
|
With this change, now *every* front-end command either accepts a count
argument, or or it doesn't accept a count at all.
|
|
|
|
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.
|
|
|
|
In #2053, I omitted to notice that the top-frame (vomnibar)
initialisation sequence also generates O(n^2) messages.
This makes that sequence O(n).
|
|
|
|
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.
|
|
|
|
|
|
There's no need for the setting of the icon to be driven from the
content script. We first know the enabled state in the background page,
so set the icon there immediately.
|
|
This tidies up some logic that was showing its age.
|
