| Age | Commit message (Collapse) | Author |
|---|
|
There's other stuff (ports, frameIds) in @tabState[tabId] that we don't
need in the front end. Here, we only send the three properties which we
do need.
|
|
This is not at all satisfactory.
I've seen cases where global link hints hangs, apparently because we do
not hear back from a frame. The issue is repeatable when it happens,
but not repeatable in general (if you reload the page, then it goes
away). This suggests that there may be something fundamentally wrong
with the global link-hints logic. However, what?
In the interim, this adds a timer to trigger link-hints mode activation
with whataver hints we do have after a short period of time.
Ideally, we'll be able to get rid of this soon.
|
|
|
|
When a link's text is particularly long, displaying all of its text
makes the hint look weird - so shorten it.
We still use the full text for matching.
|
|
Scrollable divs are offered via link hints. It makes no sense to offer
the current activated element for selection - so don't.
On a "normal" page where there's just one scrollable thing,
document.body, this means that we no longer offer the unnecessary
"Scroll." hint.
|
|
If we lose contact with a frame (it's goine away) while still awaiting
hints from that frame, then post a dummy/empty list of hints instead.
This seems very unlikely to come up, but we should guard against it
anyway.
We use "nextTick()" so that we finish sending the current message
before sending the dummy hints.
|
|
This is experimental, and may be reverted.
I suspect that the special treatment of the top frame may actually be
causing problems for global link hints (rather than solving them!).
|
|
The check that an element as an href (for certain hint modes) can be
done earlier, thereby avoid the need to pass that information between
frames.
|
|
|
|
We only need showLinkText in the hint's local frame, so do not transmit
it to remote frames.
|
|
The "reason" a hint is available is only ever needed in the hint's own
frame, so there's no need to pass it to other frames.
|
|
Previously, we passed each hints rect to every other frame. However,
the rect is only actually needed in its own frame.
Here, we instead keep (and use) each hint's rect locally only.
|
|
Previously, we were rendering hints in all frames, but displaying only
in their own frame
With n frames and m hints, we rendered n*m hints.
With this, hints are only rendered in their own frame, so we only render
m hints.
|
|
We take a copy of the frame Ids and ports at the point which link-hints
mode is launched, and use that subsequently. Therefore, a newly created
frame cannot cause the hint coordinator to become confused.
Also: add debugging code.
|
|
This fixes an error in 39adee9090fc5aadfd5dd681f91b80025084858a.
Specifically, if there are no hints to select from, or no
documentElement, then link-hints mode exits without initiating an actual
mode (i.e. without calling its super() constructor).
With 39adee9090fc5aadfd5dd681f91b80025084858a, that leaves a mode in
place which blocks all keyboard events, thereby rendering Vimium
entirely hung.
See this line:
https://github.com/philc/vimium/commit/39adee9090fc5aadfd5dd681f91b80025084858a#diff-e9abcb9ebcdb5af8e9f33651364673a1R59.
Here:
- we explicitly remove the keyboard-blocking mode
- we add exitOnEscape (so that the situation is at least
recoverable), and
- we add an indicator (so that we can see what's going on).
It is proposed that the indicator is a temporary feature, while the
global link hints feature is in shake down.
|
|
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.
|
|
I've not observed this, but it could possily happen...
If the stableSortCount gets out of sync in different frames, then
different frames might make different decisions about the ordering of
the hints.
Ti avoid this potentially happening, we initialise the stableSortCount
every time link-hints mode is activated.
|
|
Previously, we could select divs, uls, and ols for scrolling, but we
couldn't get back to scrolling the document body.
This makes it possible to select document.body for scrolling.
Unfortunately, sometimes the hint appears in a rather odd place (because
it's "on top of" something else which is clickable.
|
|
We do not need to install separate event listeners for every callback.
Just install one listener and keep track of the callbacks ourself.
This is clearer, and also determines the order in which callbacks are
called. (Although, we don't rely on that currently.)
This also adds a tests.
|
|
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().
|
|
Without considering the size of the data passed, ports seem to be about
5 times fast than sendMessage(), so we use ports of link-hint messages
wherever possible.
|
|
If document.documentElement isn't ready, then we can'r generate hints.
Moreover, this would crash -- thereby hanging global link hints.
|
|
We use portsForTab[0] instead.
|
|
This maintains a mapping from tab Ids to a mapping from frame Ids to
their ports.
|
|
|
|
Following on from f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125, I omitted to
verify that the height of the dialog was correct on taller screens.
|
|
With global link hints, hints might be launched in one frame when the
settings are not yet loaded in another. This could lead to one frame
using one settings value, and another another value. (Because we use
the default value if the settings are not yet loaded.) And this in turn
could cause link hints to crash if filetered hints are used (because, in
that case, we would not calculate hint.linkText in one frame, but then
try to use that value later in another frame).
|
|
Settings.onLoaded() is similar to Settings.use(), except it does not
require/expect a key argument.
Would could simulate .onLoaded() with .use() by artificially adding an
(unused) key, but that would make the code less clear. So it seems
better to have a separate method.
|
|
Rename handler stack constants, and rework logic for greater clarity
|
|
|
|
|
|
|
|
|
|
Problems:
- The meanings of some of the Mode/handlerStack constant names is far
from obvious.
- The same thing is named different things in different places.
This changes various constant names such that:
- the names used in the handler stack and in the modes are the same.
- ditto vis-a-vis DomUtils.
Also, break out the core of the handler stacks' `bubbleEvent` method
into a switch statements. This makes it more obvious that the cases are
mutually exclusive.
|
|
|
|
Which:
- uncovered a typo in 39adee9090fc5aadfd5dd681f91b80025084858a.
Also:
- make Mode.debug a class variable, which is more helpful while trying
to debug. Specifically, you can turn debugging on or off from
within the tests, for example.
|
|
Because there is a small amount of time between link-hints mode being
requested and it being activated, it was possible to launch other Vimium
commands (e.g. the Vomnibar) after requesting link-hints mode, and
before link-hints mode starts.
This prevents that.
|
|
The exit sequence is clearer like this.
|
|
|
|
See the newly-added comment.
|
|
|
|
|
|
Context: filtered link hints with wait-for-enter enabled. Once a link
is selected, it is highlighted. We then consume all keyboard events
until the user hits enter, at which point the link is activated.
Problem: When we're waiting, the link is highlighted. It looks to the
user like `Escape` should cancel.
This implements escape to cancel at that point in the exit sequence.
|
|
|
