| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
See the newly-added comment.
|
|
|
|
|
|
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.
|
|
|
|
Use image data for icons.
|
|
This uses image data (instead of a path) for the page icon. It also
only builds 19x19 and 38x38 icons, as per the
chrome.browserAction.setIcon() documentation.
This appears to fix a memory leak related to a recent Chrome regression
(versions 49+).
Fixes #2055.
|
|
|
|
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.
|
|
Link hints: false positives and scrollable divs
|
|
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
|
|
Global link hints
|
|
|
|
|
|
... 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.
|
