| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
It seems we cannot rely on the port being disconnected to unregister a
frame. So we need to unregister it on "unload".
|
|
There's no need for the previous complicated approach to UI component
initialialisation, in particular for the Vomnibar.
We only initialise the Vomnibar in the top frame. However, if for some
reason it hasn't been initialised by the time it's needed, then we can
just initialise it then. We are only initialising it early to avoid
flicker, so it's not a correctness issue. And the only reason it
wouldn't be initialised is if Vimium is disabled in the top frame, but
enabled in some other frame -- which is not a common case.
|
|
We need to wait for documentReady() here to ensure that the document is ready in the top frame.
|
|
There seems to be an issue on this page:
- http://i.imgur.com/PdmUjij.jpg
whereby "DOMContentLoaded" isn't firing. The page structure is unusual
(involving a shadow-DOM element), which might be the source of the
problem.
What happens is that the "DOMContentLoaded" event fires as required, but
the document state is still "loading".
Here, we just say that if the "DOMContentLoaded" handler has fired
once, then we're good to go.
|
|
This affects focusFrame and link hints.
We do not register tiny frames. The reason for doing this is that link
hints messages all (registered) frames to collect their hint
descriptors. On some sites (e.g. Google Inbox and other Google
properties), there are many tiny iframes (on the order of 12 or 15 or
so). Those frames cannot provide useful hints, so -- by not registering
them -- we don't ask them for hints.
The intention is to speed up the link-hints activation sequence.
|
|
The reason for doing this is that we will be using the same test to
decide whether or not to register a frame.
|
|
This is a no-op.
It separates the process of registering a frame with the background page
from the port initialization. The idea is that -- soon -- we will only
register some frames; in particular, we should not register the many
tiny iframes on pages like GMail.
The eventual goal is to speed up the global link-hints initialisation
sequence.
|
|
This seems to be considerably faster than using sendMessage().
|
|
See the newly-added comment.
|
|
|
|
TODO:
- fix tests
|
|
With several frames, only one frame can call sendResponse(), whichever
one happens to call it first.
getScrollPosition, is the only handler for which we care about the
response. Here, we make sure that sendResponse() will *only* be called
in the top frame - where we want it called.
This fixes a possible race condition in global marks.
Additionally, although it's not the primary intention here, this also
avoids calling sendResponse() unnecessarily in cases where we don't use
the response.
|
|
There were two problems, both stemming from the fact that the
notification was being displayed in the top frame, even if the mark was
triggered in another frame:
1. That looks odd, because we close the HUD in one frame then open it in
another.
2. As a side effect, we were moving the focus to the top frame.
Here, we work out what's going to happen before sending the message to
the background page. This allows us to display the message in the HUD
in the frame which generated it.
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
