| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This works around FF issue 554039, which prevents window.top.focus()
from working.
|
|
event.keyCode` is depricated:
- https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
|
|
|
|
|
|
|
|
New command option to enter normal mode
|
|
|
|
Previously, the dynamic HTML for the help dialog was generated on the
background page. The HTML itself was tangled in with program logic.
Here, we move all of the HTML to HTML5 templates; also, we build the
help-dialog contents in the help dialog itself, not on the background
page.
Note: #2368 is included here too.
(Background: I'm trying to clean up some of the command and help-dialog
logic in preparation for addressing the issue of how to document command
options, see #2319.)
|
|
|
|
|
|
Here's the problem...
Many sites define their own keyboard shortcuts, for example Google Play
Music defines `gh` for "go home".
On such sites, it's natural to set up pass keys for `g` and `h`.
But that makes any Vimium key bindings which begin with `g`
inaccessible.
Here, we add a new command `enterNormalMode` which installs a new
normal-mode instance (without any pass keys). This executes a single
normal-mode command then exits.
Example:
map \ enterNormalMode
map | enterNormalMode count=999999
Assuming `g` and `o` are pass keys:
- `gh` or `o` - use the page's binding
- `\gg` - scroll to top
- `2\ggo` - scroll to the top and open the Vomnibar
- `\g<Escape>o` - open the Vomnibar
- `\<Escape>o` - use the page's bindings
- `\\\\\\<Escape>o` - use the page's bindings (new normal-mode instances
displace previous ones)
This required some changes to the scroller. Previously, we only ever
had one normal-mode instance, and could arrange statically that the
scroller's key listeners were above normal-mode's key listeners in the
handler stack. Here, we fix this by adding and removing the scroller's
listeners dynamically, so they're always at the top of the handler
stack.
|
|
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 the user begins interacting with one frame, we disable the
grab-back-focus mode in *all* frames.
Previously, grab-back-focus was preventing users from selecting inputs
in frames other than the active frame.
Fixes #2296 (possibly).
|
|
Comminication by the frame's port is faster, and no response is sent.
|
|
Partially addresses #2303.
|
|
If the user is jumping to a scroll position within a tab, then we need
an exact match on the URL (because otherwise the scroll position doesn't
really have a meaning). Otherwise we only require a prefix match, a la #2250.
|
|
Due to a typo, VisualLineMode is broken in 1.55.
Fixes #2146.
|
|
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).
|
|
|
|
next/prev links
|
|
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.
|
|
left/right angle quotation marks
|
|
|
|
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.
|
|
This reverts commit c01d7eea8675f9a7d84999777e8de72244d687b6.
Preparatory to implementing an alternative approach.
|
|
|
|
The Vomnibar isn't needed on most tabs, so don't init it.
I cannot detect any sluggishness as a result of this.
|
|
This avoids initializing around 15 (almost all unused) HUDs on sites
like GMail and Google inbox.
Because the HUD is small, there is not noticable flicker.
|
|
Replaces #2037.
|
|
|
|
In 5c3e4bda2968486e23f8cc3410e776de67fec849, I omitted to observe that
we need to know whether the window has the focus *before* the DOM is
ready when checking whether Vimium is enabled.
This fixes that.
|
|
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.
|
|
|
|
Remove special-purpose code from `gf`.
Instead, register the help dialog frame when it launches, and unregister
it when it's hidden.
This way, when the helpd-dialog frame is hidden, it simply isn't
available for `gf` and for link hints.
|
|
|
|
When the help dialog UI component has been created but subsequently
hidden, `gf` was nevertheless selecting it.
|
|
|
|
The code to handle the focus for UI components has been tweaked and
adapted over time, and has become quite complicated (and brittle). This
reworks it from scratch, and co-locates similar code which does related
things.
Fixes #2099.
|
|
Assume there is an existing range selection.
Consider `v`, `Escape`. Previously, this had the side effect of
clearing the selection. That behaviour seems odd and wrong.
Here, we retain the selection if there was an existing range selection
when visual mode was launched.
Arguably, this removes a "feature" whereby `v`, `Escape` clears the
selection. Here, we take it that the oddity above outweighs the loss of
this arguably unintentional "feature".
|
|
Here's the trade off... We either *always* initialize the help dialog in
every frame of every tab, or we initialize it only when needed.
The help dialog is rarely used by anybody except beginners, so the
latter seems like the better approach. However, on busy/slow loading
pages, the help dialog can fail to load on page start up. (We need to
fix this, but I don't know how right now). In the meantime, the better
compromise seems to be to initialize the help dialog only when needed.
This was the status quo prior to 6e12e005a4261711583571be23018481a4a23230
and 09e119db8d8c3ad2077ac509f73fefb76a08fac0.
|
|
|
|
On a slow loading page, as the page is loading, hit `o` repeatedly.
Eventually, Vimium hangs.
We seem to have had this problem for quite some time (e.g. it's in
1.54).
This fixes the problem by ensuring that the Vomnibar is initialized
before launching it.
Also fix the same issue for the help dialog.
|
|
1. Do not initialize UI components until the DOm is ready.
2. Do not register UI components as ready (specifically the HUD) until
the full initialization sequence is complete.
This goes some way towards fixing the issue described in this comment:
https://github.com/philc/vimium/issues/2081#issuecomment-205758102
It relates to link-hints mode hanging when launched during a navigation.
This problem exists in 1.54, but emerged during testing of global link
hints.
"Some way toeards fixing..." because it is still possible to trigger
issues.
|
|
- 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.
|
