| Age | Commit message (Collapse) | Author |
|---|
|
Clean up, and fixes following code review from @mrmr1993.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This changes vomnibar commands to activate not in the current frame, but
in window.top. Consequently, the vomnibar always appears in the same
position, and we don't get odd looking vomnibars in small frames.
Apart from the better UX, this seems to be the right thing to do.
Vomnibar commands apply to tabs (not frames).
Currently incomplete:
- On exit, the focus is not returned to the frame which originally
had the focus. (It's returned to window.top).
- The vomnibar can lose the focus and not hide itself for various
frame/click combinations.
|
|
In b05276ed8264e5a71f20a7068690ba2a414ee6d8, I inadvertently moved the
focus handler from window to document. As a consequence, detectFocus
(now registerFocus) wasn't being called when expected.
|
|
Move scroller initialisation so that its key handlers are above insert
mode in the handler stack. This ensures that the scroller sees keyup
events if we enter insert mode while continuous scrolling.
Fixes #1526.
|
|
This is @mrmr1993's work from #1041.
Reload content scripts when vimium is installed or updates.
(@mrmr1993: The automatic merge was really messy (or, at least, I
couldn't figure out what was going on). Since the bulk of #1041 was
actually quite compact, I took the liberty of just copying it in. Hope
you don't mind.)
|
|
|
|
|
|
This adds another handler which is delivered to the options page, but
for which there is no handler. This was causing an exception on the
background page (console).
|
|
.. and don't forget to actually use the incognitomode flag in the front
end.
|
|
See #1495.
|
|
|
|
Rationale. There are really two insert modes: the one we activate with
"i" and the one that's activated when a focusable element receives the
focus. This makes that distinction clearer. And, in particular, it
means that, when the latter type of insert mode is active, we *know*
that gloabl insert mode is *not* active.
|
|
|
|
Doh! I didn't know this existed.
|
|
- 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
|
|
If an input grabs the focus before the user interacts with the page
(keydown, mousedown), then grab back the focus.
TBD:
1 This requires a new option, which has not yet been added. For now,
it's just permanently enabled.
2 There's a race condition between the setting being loaded and the
element being focused. Currently, this defaults to being activated.
This is the wrong thing to do. The solution is probably to use
chrome.storage for the setting.
3 The tests fail (because of TBD-2, above).
|
|
- Show the URL in the HUD (improved quality of feedback).
- Change HUD delay from one second to two seconds - I find one second
too short for the message to be useful. It's often gone before I look
to check. And two seconds (hopefully) isn't so long as to be
annoying.
|
|
Conflicts:
background_scripts/main.coffee
|
|
|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
lib/keyboard_utils.coffee
|
|
|
|
|
|
Approach:
- We never save the find mode history from an incognito tab in the
settings, instead they are saved in the tabMapInfo for each
currently-active incognito tab.
- When a new incognito tab (or page, after navigation) starts, we
scan the tabMapInfo looking for the find-mode history of any active
tab.
In this way, the history is shared between incognito tabs, but discarded
once the last incognito tab closes.
|
|
|
|
|
|
The approach is to maintain the "current" history in every tab, adding
queries from other normal tabs in all tabs, but only saving queries from
non-incognito mode tabs.
So, queries from non-incognito mode tabs propagate everywhere, whereas
those from incognito tabs never leave the tab.
|
|
|
|
- This commit is incomplete because, to progress, we need bc7db7473456713c8c84f324e71da93145ffa2a0.
|
|
|
|
|
|
|
|
Doing the migration in a content script is dumb. Now we do it on the
background page.
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
The stripped code is all relocated in #1413.
|
|
If focusInput does not find a visible input, then pop up the HUD to tell
the user. Without this, the user gets no feedback as to what happened.
|
|
|
|
This was an oversight from #1413 (that find mode exits in this
circumstance).
|
|
|
|
|
|
|
|
|
