| Age | Commit message (Collapse) | Author |
|---|
|
We were leaking the keydown event to the page when using TAB to select
link hints (filtered hints).
|
|
Error was introduced by seemingly innocuous but nevertheless significant
change in previous commit.
Tests picked up the problem.
|
|
For filtered link hints, " " was broken; it was treated as "space".
|
|
|
|
event.keyCode` is depricated:
- https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
|
|
|
|
|
|
|
|
|
|
Example page: http://codeforces.com/contest/752/problem/B.
There, `element.tagName` is an element with `name` `tagName` (not a string). Here, we guard against that case.
Fixes #2305.
|
|
|
|
Makes sure all custom link hint characters defined in settings are lowercase
|
|
|
|
case when link hints are generated
|
|
This is a no-op. It arranges that the registry entry for each command
is passed to the command, for every command.
That required a small ammount of reworking in a couple of cases.
|
|
When an <a> spans the end of a line and the start of the next line, we
now highlight both parts of the link (instead of just the first).
Also, refactor code for calculating the position of the viewport into a
separate utility in DomUtils.
|
|
|
|
Google seems to be using a lot of "title" attributes on buttons. This
makes it possible to type the text in filtered link-hints mode. (And
you can often guess the text; e.g. "close").
We could also show the title text. That is very visually noisy though,
in practice.
|
|
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.
|
|
Thinking about it more carefully, this algorithm is always O(n^2).
|
|
Do not set the style on the active hint marker if it's in another frame.
|
|
Applies to filtered hints only.
|
|
The prevents the active element from being reset when we rotate hint
markers.
|
|
When the user selects an active hint with Tab (for filtered hints),
adjust its z-index such at it is top of the stack.
|
|
|
|
|
|
|
|
It is common for link-hint markers to be close togother, and
overlapping.
Here, `<Space>` rotates hint markers such that hidden markers become
visible.
For filtered hints we additionally require a modifier (because `<space>`
on its own is already a token separator).
The calculation of overlapping hints is quite expensive: O(n^2) in the
best case and O(n^3) in the worst cast. The worst case is
extraordinarily unlikely to arise in practice.
|
|
hint a label only if its control is not disabled
|
|
example:
``` html
<label><input type=checkbox disabled />exlpanation</label>
```
|
|
|
|
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.
|
