| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
hint a label only if its control is not disabled
|
|
Add support for opening details elements
|
|
Consider the alt-key status when trying to detect <c-[>
|
|
example:
``` html
<label><input type=checkbox disabled />exlpanation</label>
```
|
|
Chrome stop using <backspace> to go back, but some still wants this
feature.
This should fix #2207 and #2214.
|
|
|
|
see https://github.com/philc/vimium/issues/986#issuecomment-53955175
|
|
Mention edit URL keybindings
|
|
Tracked down some keybindings I was after under #1004
Added them to the main documentation.
|
|
This reverts commit 2526bb3b0433e5cf645dfd7007ec42860b11ba2a.
See #2164. It seems this is no longer necessary.
|
|
Adds important to hint marker font-family declaration
|
|
|
|
|
|
|
|
See #2147.
Chromium's implementation of event.key currently fails to take account
of keyboard mappings (e.g. neo2).
Here, we favour using event.keyIdentifier (while it's available) as a
workaround.
|
|
|
|
Due to a typo, VisualLineMode is broken in 1.55.
Fixes #2146.
|
|
Adds single left/right angle quotation marks to next/previous patterns
|
|
Now that 1.55 has been released, we should note this new command in the
README.
|
|
|
|
|
|
Use event.key (not event.keyIdentifier).
|
|
|
|
This was an oversight from a5262f4e68f62a922c9c05d871c4a874f6737a7b.
|
|
event.keyIdentifier is depricated and will be removed soon. It is being
replaced by event.key. Unfortunatelty, event.key is not yet available
in the stable Chrome version.
Here, we use whichever API is available. In due course, we can remove
the event.keyIdentifier implementation (and a considerable amount of
machinery surrounding it).
For the time being, if both APIs are available, then we verify one
against the other and show a warning message of they do not match. This
should help us track down any issues which arise.
Using event.key has the additional benefit of correctly detecting
shifted characters on the numbers row on keydown, which has been a
problem for some users.
Fixes #2128.
Note: We have a problem with the tests. phantomjs does not currently
support event.key, and possibly never will.
|
|
|
|
If the link's value is not a string, then the previous version of this
fails. The new test will be false for such links.
|
|
adding single left/right angle quotation marks"
This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff.
This reverts #2117.
This breaks next/prev on Reddit (it chooses a different link).
Reddit is an important site, so we should unwind this for now.
Mention @sco-tt.
|
|
|
|
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.
|
