| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
Replaces #2037.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
When we introduced command options (for mapping keys to custom-search
engines), the parsing was done in the Vomnibar code.
This moves the parsing to `commands.coffee`, which is where it should
always have been.
This is a preliminary step with a view to adding a new `count` command
option.
|
|
|
|
"Flags" implies binary toggles. The term "options" seems more
consistent with what's actually going on here.
|
|
For ...
map s Vomnibar.activate keyword=g
... we verify that "g" is indeed a custom search-engine keyword before
setting it. If it is not, we output a console.log message and launch a
vanilla vomnibar. (An alternative would be to bail.)
|
|
This avoids a flicker whereby the keyword is first inserted into the
input, then removed.
|
|
Now, a mapping of the form:
map s vomnibar.activate keyword=g
makes the vomnibar open (on "s") with the Google custom-search engine
activated immediately (assuming it's configured).
The corresponding custom search-engine configuration would be:
g: http://www.google.com/search?q=%s Google
|
|
1. Rework event handling to eliminate frame flicker (a la #1485).
2. Tidy up logic. Which should make this more robust.
|
|
|
|
|
|
|
|
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.
|
|
Accidentally dropped in 1bc415536fe45ad40ac37282ea54644361ec73f7.
|
|
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.
|
|
|
|
|
|
|
|
sukima-feature/edit-url-in-vomnibar
Conflicts:
background_scripts/commands.coffee
|
|
|
|
|
|
|
|
functionalities
|
|
|
|
fixes #1005
|
|
|
|
Often times when I'm working on sites I want to add a query string or
modify the port number. The go up one level or root of the URL commands
are nice but they don't alow you to add or remove specifics on the
current URL.
This adds two commands that act exactly like the normal onmibar open but
populates the bar with the current URL.
I picked `ge` as the default and `gE` as the default for the same in a
new tab.
|
|
|
|
|
|
|
|
It's pretty natural to hit CTRL+N and CTLR+P to select a choice, and then CTRL+enter to open it in a new tab.
But previously that didn't work on mac.
|
|
This *should* fix the permission problems that `eval` faced.
Closes #575, #710.
|
|
|
|
Closes #687.
|
|
Previously, handlerStack was designed only for removal of the handler
right at the top of the stack. However, some handlers sought to remove
themselves when they were not at the top of the stack, creating
confusion. The new handlerStack ensures that such removal can always be
done safely.
|
|
Closes #670.
|
|
|
|
|
|
Errors were detected using coffeelint.
|
|
'B' is a new command for searching for a bookmark and opens it in a new
tab.
'O' now searches through history and bookmarks and opens the selected
item in a new tab. Previously, it started vomnibar with the current URI
selected and opened the selection in the same tab.
This fixes #594.
Signed-off-by: Carl Helmertz <helmertz@gmail.com>
|
|
more resistant to a site's css.
Previously the vomnibar didn't look great on Quora because of this.
|
|
|
