| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This is a workaround for Firefox bug 1408996.
|
|
|
|
Try the following....
- load page
- `/`
- type some junk which matches nothing
- `Escape`
We expect to leave find mode. Instead, we have to hit escape again to
get out of find mode.
Here, `focusNode.focus()` is not a function.
|
|
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.
|
|
Previously, we were transferring a "transferable event" from the HUD UI
component to the content script (when find mode exits).
In addition to being unnecessary, this was triggering a warning in the
console because we were reading *all* of the events keys, including one
which triggers a "this is being deprecated" warning.
The approach here is simpler, transfers less data and avoids triggering
the warning.
|
|
If the help dialog loses the focus and closes, then we abandon any HUD
which is being displayed. This ensures that - when the help dialog is
reopenned - we're not displaying an old, out-of-date HUD message.
|
|
This replaces c01d7eea8675f9a7d84999777e8de72244d687b6.
All UI components require the document to be ready. So, here the
constructor waits for DomUtils.documentReady(). The diff looks big, but
mainly it's a result of changes in indentation in the constructor and in
hide().
Also, hide() now uses @postMessage() to post a null message. This
forces hide to use @iframePort.use(), which ensures that hide()s cannot
overtake activate()s.
This continues #2100.
|
|
This reverts commit c01d7eea8675f9a7d84999777e8de72244d687b6.
Preparatory to implementing an alternative approach.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
The front-end initialisation sequence has become quite confused.
This simplifies it, makes things which must be idemtpotent explicit and
renames some functions to make it clear when they run. It also avoids a
situation where we were possibly installing a `domReady` function to
initialise the HUD multiple times.
Should be a no-op functionality wise.
|
|
HUD: Initialize only when the frame receives the focus and Vimium is enabled.
Vomnibar: Initialize in the top frame when Vimium is enabled in *any* frame.
Warning: There may be a race condition here. Specifically, if Vimium
is disabled in the main/top frame (T) but enabled in another frame (A), then the
initialisation could happen in frame A before frame T is listening, so
frame T would miss the initialization message (which is only sent once).
Message listeners are installed early (and probably installed first in
the main/top frame), and the `isEnabledForUrl` messaging takes some
time, so perhaps it's OK. But it *is* a race condition.
Fixes #1838.
|
|
|
|
This makes the `hideHud` option apply only to insert mode (when entered with `i`).
Fixes #1953.
Fixes #487.
We could rename the option itself and add migration code, but that seems overkill.
An alternative would be to remove this option entirely.
|
|
This implements @gdh1995's idea from #1796.
|
|
|
|
This code belongs together, so we put it together.
|
|
This undoes the effect of the breaking refactor in
73f66f25e6b8e5b5b8456074ad4fa79ba1d3ca4d, where PostFindMode was entered
whenever FindMode was exited, instead of only when it was exited with
<enter>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was broken by the move to taking input in an iframe, since the
frontend was no longer getting keydown events for text changes, and so
the viewport wasn't being scrolled back to its original position until
the mode was exiting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Mis-named: "handler" -> "name".
- We need to reset the HUD's innerHTML on hide to avoid a flicker when
HUD later becomes visible again (but with new text).
- There is no longer a need to hide the HUD in order to avoid mathing
the text in the HUD itself.
|
|
|
|
Alternative to 7004420e178416cc680416091a23dd804fb9370c.
|
