| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
|
|
1. Rework event handling to eliminate frame flicker (a la #1485).
2. Tidy up logic. Which should make this more robust.
|
|
Since the vomnibar now always is initialised and opened the top window
(see d67347461da5a0468547e4c807a54bb40746faf4), there's no longer a need
for this to be a Vimium Labs feature.
|
|
|
|
|
|
|
|
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
|
|
Setting the page icon is now driven from the corrently-active frame.
- Eliminates a race condition.
- Icon matches actual frame state (not tab URL state).
- Exclusion-rule changes propagate to all frames.
|
|
Previously, we have been populating the suggested exclusion URL in the
page popup with the tab's URL. This uses the active frame's URL
instead:
- because this is the URL which will affect the current frame (without
this, a user can naively add an exclusion rule and it has no effect),
and
- because, without this, the user has no reasonable way to add exclusion
rules for frames such as the hangouts frame on gmail (for which, the
URL is not displayed in the address bar).
|
|
|
|
This delivers a "hidden" massage to the vomnibar after the vomnibar has
been hiddent in the host page. The vomnibar only performs whatever
action is required when it receives this "hidden" message.
|
|
This is not entirely satisfactory. It would be great if a delay of 0
worked (a la `nextTick`). But it seems we need a little longer because
we need to allow the UI component messaging to complete.
An alternative would be to thread the action required through the UI
component logic. But that's pretty ugly too.
Yet another alternative would be to have the UI Component post an "ok,
we're done, do it" message once the UI component has been removed.
Fixes #1485.
|
|
Click:
- in the vomnibar focuses the input
- anywhere else (such as in the space below the vomnibar) hides the
vomnibar.
This makes clicks in the space below the vomnibar behave the same as
clicks in the page itself... Which makes sense, because the difference
is not apparent to the user.
|
|
Fixes #1506.
This takes the opposite approach to #1511. Instead of hiding the
vomnibar when it blurs, we hide it when it's host frame is focused.
|
|
- Fix incorrect camel case in option name.
- Better text on options page.
- Loud comments re. using option directly from chrome.storage.sync.
|
|
- add new option "GrabBackFocus"
- use chrome.storage.sync.get() to get option value
- avoid race conditions on load
- fix tests
|
|
In #1389/c52c0ea57f86c1c5a132819fe85e763db84ce712 we added descriptions
to search engines. We (I) omitted to realise that the "type" of a
selection (in particular, the constant "search") is also used to
determine whether the suggestion is automatically selected by the
vomnibar.
This fixes that, such that custom search engines with descriptions are
now automatically selected in the vomnibar.
|
|
In tabs mode, the vomnibar is pre-populated when the query is empty.
If, as part of hiding the vomnibar, we reset it, it becomes populated
again, so the display style is reset from "none" to "block". Therefore,
the completion list is briefly visible when the vomnibar is later
reactivated.
Solution:
- Do not run `@update()` from `@reset()`.
|
|
https://github.com/smblott-github/vimium into smblott-github-search-engine-descriptions
|
|
|
|
|
|
|
|
|
|
As @philc pointed out in #1366, this is less brittle.
|
|
|
|
From top to bottom on the diff:
- The echo handler on the background page is no longer required.
- Simplify/refactor vomnibarUI message handler.
- Initialise vomnibar query to "" (rather than null) and simplify.
- No need to focus parent window when vomnibar closes; that's handled by
the iframe framework. Also no need to blur.
|
|
|
|
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
manifest.json
|
|
|
|
- Simplify component API.
- Iframe flashes on re-focus.
- Probably some other stuff which I've forgotten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The problem with 40a64e3d47a06548b18231f19a86631aa1ef265b had nothing to
do with spellchecking, but instead was an issue to do with the placement
of whitepsace within exclusions.html
|
|
This reverts commit 40a64e3d47a06548b18231f19a86631aa1ef265b.
This was causing *all* rules to be displayed. Will revert until I
figure out why.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
