| Age | Commit message (Collapse) | Author |
|---|
|
Fix UI-component initialization issues (maybe).
|
|
Fix link-hints failing to launch.
|
|
Sometimes, link-hints mode fails to launch. See Issue 1 from this post:
https://github.com/philc/vimium/issues/2081#issuecomment-210980903.
Here's a reproducible case:
- visit twitter
- using the vomnibar, visit any other page (in the same tab)
- hit `f` - the link hints fail to load.
What's happening is that the unregister/register frame messages for the
main/top frame arrive in the wrong order (first register, then
unregister). Because these both have the same frame Id, the effect is
that the main/top frame ends up not registered. So there are no
registered frames, so link hints mode doesn't launch.
Only the main/top frame has a re-usable frameId (`0`). All other frames
receive a unique frame Id (which is never re-used).
Here, we just never unregister the main/top frame. That way, it doesn't
matter which order the register/unregister messages arrive in. If the
tab is navigating to a new page, then there'll be a new main/top frame
along soon. If the tab is closing, then we tidy up in the
`chrome.tabs.onRemoved` handler.
|
|
This affects binary search in the history cache.
The returned index can be one beyond the end of array, and so we get an
error when we look it up blindly. So, we need to check.
|
|
install the real selectionchange listener after window.find
|
|
|
|
Make findAndFollowLink look at element values so <input> can be used …
|
|
|
|
next/prev links
|
|
Do the following:
- `b`, `Tab`
The Vomnibar crashes. The problem is that we're advancing the selection
even though there are no suggestions available.
Here, we require there to be a suggestion or suggestions before
advancing the selection.
|
|
This fixes some UI component initialization issues. It's a long
story...
The problem.
- Go to this page: http://www.thejournal.ie/seanad-election-results-2016-2737768-Apr2016/
- Click one of the links from the "Most Popular" box on the right.
- Navigate back (`H`) and, as the original page is loading, activate the Vomnibar.
In 1.54 this renders Vimium unusable. In `master` this renders the
Vomnibar unsable, but the rest of Vimium usable.
It seems the source of the issue is that we're initializing UI
components too soon. We need to wait until the `readyState` is
"complete".
With this PR:
- The Vomnibar is initialised when the `readyState` is "complete" (in
the top frame only, and only if Vimium is enabled). Requests arriving
prior to then are silently discarded.
- The HUD is also initialized only when the `readyState` is "complete";
however, requests arriving before then are queued. So, if the user
immediately enters insert mode, then the "Insert mode" indicator will
eventually be displayed.
- The help dialog silently discards requests until the `readyState` is
"complete.
I'm posting this as a PR because:
1. It needs some visibility.
2. With this, if the `readyState` *never* reaches "complete", then the
Vomnibar would be unusable. And that's pretty serious.
|
|
There are circumstances when we hav two (identical) vimiumFlash elements
displayed: specifically, when using the waitForEnter keyboard blocker.
So, we should use a class (rather than an id) to style the flash
element.
|
|
I seems that we cannot rely upon either the "unload" event in the
content script or the port's onDisconnect handler there to unregister
frames.
To see this, go to a frame-busy page like this one:
- https://www.theguardian.com/technology/2016/apr/26/apple-iphone-first-revenue-decline-13-years
and then navigate to any other simple page (in the same tab). Navigate
back and forward with `H` and `L`.
If you watch frames registering anf unregistering, almost all of the
frames from the frame-busy page do not unregister.
Here, we unregister frames on onDisconnect in the background page too.
It is possible that this is the source of the problem mentioned as point
1 in this comment:
- https://github.com/philc/vimium/issues/2081#issuecomment-210980903
And for which #2116 is a workaround.
|
|
Improves next/previous links by targetting button elements and adding…
|
|
left/right angle quotation marks
|
|
|
|
It reads weird on the helpd dialog if we don't put the full-page and
half-page commands in a similar order.
|
|
Modernize help dialog styling
|
|
On the help dialog, use the same blue of the "Vim" of "Vimium" for
links.
|
|
- Re-order commands such that we keep like with like, and have the more
important commands nearer the top.
- Re-word some command descriptions such that we use the same words for
the the same thing consistently.
- Move "View Source" to the "Miscellaneous" category.
- Make some commands "advanced commands".
|
|
|
|
If we're not using the previous font for other links on the help dialog,
then it doesn't make sense to use that font for command names either.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Make the font size (and color) match those used in the footer.
|
|
|
|
It's pretty undiscoverable that you can click command names to yank
them. So, this adds a tip to the bottom of the help dialog.
Also, change the cursor to a pointer when hovering over command names.
|
|
- Style the links at the top the same as those at the bottom (re.
colour).
- Fix HTML indentation.
|
|
The commands names (in the help dialog) look nicer in italics. They
also format better that way.
|
|
Use margins to centre the help dialog. This works better on narrow
windows, and seems to produce a balanced dialog in a variety of cases.
|
|
This gest the centring calculation correct.
Also, remove the shadow; it's not visible.
|
|
|
|
This needs more work.
|
|
|
|
|
|
|
|
This mimics the look of Google Inbox or Github.
The background colour is from Google Inbox, Github uses a slightly
lighter colour.
|
|
It's not clear when -- possibly when we moved the help dialog to an
iframe -- the links at the bottom of the help dialog stopped working.
Here, we reinstate them by opening the referenced page in a new tab.
This is consistent with the behaviour of the links at the top of the
help dialog.
Also, the "please review us" link now points to the "reviews" tab on the
Chrome store.
|
|
Prime focus input on the Vimium options page.
|
|
|
|
This is a bit of a hack, and pertains to focusInput (`gf`).
The problem... On the options page, there are *lots* of inputs
(specifically, for every exclusion rule there are two inputs). This
makes `gf` almost unusable. It's impossibly to `Tab` through them all.
Here, on the options page, we prime the pre-selected input to be the
key-mappings input:
- arguably, this is the most frequently used input, and
- other inputs (such as custom search engines) are just one `Tab` away.
|
|
This effectively reverts 4b564e8517dd3415cb8e2209ce019fa024e88770.
Reinstate pre-initialization of the Vomnibar.
Without pre-initialization, there is a small but noticable sluggishness
the first time the Vomnibar is opened.
|
|
Previously, you could blur the help dialog on the options page (to read
and type command names).
With the reinstated help-dialog styling (whereby the help-dialog iframe
extends across the entire window), this doesn't make sense. So it's
removed.
|
