| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I haven't seen this happen, but...
It could be possible for the iframe's contents to load before this
callback is called (on nextTick), in which case the "load" callback
wouldn't be called. So we delay setting the iframe's source until
nextTick has elapsed.
|
|
|
|
Approach: Re-use the existing AsynDataFetcher class to "fetch" and use
the iframe message port. Messages are queued until the iframe's
contents have loaded and the message port is open.
Fixes #1679.
|
|
|
|
This ensures that \\\r is interpreted as {escaped-\}{escaped-r} rather
than \{escaped-\}r.
|
|
This fixes #1673
|
|
See #1671.
The problem was that we were making the vomnibar visible in the frontend,
even if the vomnibar initialisation was not yet complete, and the iframe
port was not yet available.
(Also, @activate() is never being called without options, so we can drop
that test.)
Fixes #1671.
|
|
- 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.
|
|
Following on from #1652, vimium was failing to initialize correctly on
the options page.
Specifically, installListeners() was running before
initializeOnDomReady(), hence before HUD.init(). installListeners()
runs new GrabBackFocus(), which hides the HUD, which is not yet
initialized - so it fails.
This is a temporary fix. Could you take a look, @mrmr1993? Perhaps
there is a race condition which only arises on the options page. It may
be enough to just have HUD.hide() silently pass if @tween is not yet
set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make GrabBackFocus work for javascript page transitions from links
|
|
This fixes issue #853.
|
|
|
|
|
|
|
|
|
|
This reverts commit 061e99f895e5655d351ad1585af028a12abf3ec0.
|
|
This reverts commit f1e46d8145c834a712f6be7c1e5bd590c72da749.
|
|
Use a shadowDom for the Vomnibar (and all UIComponents)
|
|
If we use contentText, then it is possible for a child and its to
have exactly the same content text, in which case it is arbitrary as to
which is sorted first, hence which we choose (where we should be
choosing the child).
Using innerHTML instead, we guess that even if the contentText lengths
are the same, the innerHTML of the parent will be longer (since it
contains that of the child).
|
|
|
|
We need to sort elements by their text length. This allows us to
exclude the text of descendants from the hint text generated for their
ancestors.
Note: Tests not yet fixed.
|
|
|
|
This reverts commit 6e7b04692aceeed6544510f853eb58cdad564f9e.
|
|
Shadow DOM doesn't support <link>s, so we have to load the stylesheet
manually and inject it into a <style> element.
|
|
|
|
|
|
This reverts commit 26cbeba9b9301652d15e01ad4dac9248637ba3eb.
|
|
This insulates them from page CSS, so we don't have to compete to style
elements correctly.
|
|
Fix over-riding of vomnibar display CSS.
|
|
This turned out to be trickier than expected. It turns out there's a
period after document.body is defined but before the DOM is ready when
we can't use the HUD (but previously thought we could, ie. HUD.isReady
returned true).
|
|
|
|
This reverts commit cfb137d515e6f214322538fdd9a8e236445b63b0.
Conflicts:
content_scripts/vimium_frontend.coffee
There are HUD initialization issues with this.
|
|
|
|
Fixes #1594.
|
|
The tests are passing, but they are triggering an exception in the
initialization of the HUD. It's proving difficult to get the
initialization in the right order for both the tests and live.
This is a temporary fix...
|
|
This reverts commit ed7533b48f2f0c7cdd0272f9c6c61c44cfc5c463.
This was somehow(?) causing the HUD to not be displayed.
Need to come back and look at the tests issue.
The tests are passing, they just generate an exception.
|
|
smblott-github/fix-grab-back-focus-after-web-navigation
Fix grab back focus after web navigation
|
