| Age | Commit message (Collapse) | Author |
|---|
|
LinkHints.init() isn't doing anything.
|
|
This is a minor re-working of #1705 from @mrmr1993.
The main changes are:
- Simplify initialisation logic.
- Always initialise Settings immediately and automatically (ie. don't
initialise Settings separately and manually in the background,
content scripts, options and tests).
- Get rid of addEventListener (it's only being used for on "load").
- Add Settings.use() in its place.
|
|
|
|
If we use contentText, then it is possible for a child and its to
have exactly the same content text, in which case it is arbitrary as to
which is sorted first, hence which we choose (where we should be
choosing the child).
Using innerHTML instead, we guess that even if the contentText lengths
are the same, the innerHTML of the parent will be longer (since it
contains that of the child).
|
|
|
|
We need to sort elements by their text length. This allows us to
exclude the text of descendants from the hint text generated for their
ancestors.
Note: Tests not yet fixed.
|
|
|
|
This requires passing of an extra truthy argument in order to access the
(generally) unexpected behaviour of sometimes returning the rects of
child elements. All locations in the code that *actually* wanted this
behaviour have been updated to continue using it.
Also add a comment about the unexpected behaviour in the function
description.
|
|
|
|
|
|
If the element does not have an HREF, then we shouldn't be offering to
copy it's link.
|
|
Note: We probably shouldn't be offering these links at all.
|
|
|
|
|
|
|
|
|
|
The page (or another extension) sees keydown events (such as shift)
before entering link-hint mode. So we need to also pass the
corresponding keyup events.
Fixes #1522.
|
|
This only effects link hints with "Use the link's name and numbers for
link-hint filtering" enabled.
We have been matching the *entire text content* of each link-hint
element.
With two (or more) hints, and with one of the elements a descendent of
the other, we have been using the entire text content of the outer node
(which includes the text content of the inner node). This leads to odd
situations where the inner element cannot be selected just by typing its
text, because its text is a substring of the outer element's text.
For example, on Google calendar, the "Today" button shows up as two
hints, one inside the other. Typing "today" never disambiguates the
hint. You always have to hit enter.
There's another nasty example on feedly, where an outer container is
clickable, but its text contains all of the (many) texts of the (many)
contained links. So the hint always has to be selected manually.
Here, when generating the text for an element, we exclude the texts from
any descendent node which has already been considered.
|
|
A modal-browsing framework
|
|
|
|
|
|
Mainly reduce code duplication.
|
|
|
|
This fixes #1096.
|
|
|
|
|
|
|
|
|
|
Also:
- visual-mode template should block insert.
- hint mode should exit on click.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Elements with `tabindex="n"` for parseInt(n) < 0 cannot be selected by
pressing the tab key, according to the spec. If we have no other reason
to suspect that the element is clickable, we may as well ignore them.
|
|
|
|
Disables showing link hint for elements which
* are identified as clickableonly by the tabindex attribute, and
* have the entirety of their contents overlapped by other clickable
elements.
This removes some redundant link hints that were visible on Google+, and
hopefully shouldn't remove any useful link hints.
|
|
|
|
|
|
|
|
|
|
|
|
This was adapted from PR #1316, commit
846a19efe51bfc639ae1ee84e18a5f2d3e12aaff
|
|
|
