| Age | Commit message (Collapse) | Author |
|
There's no need for the setting of the icon to be driven from the
content script. We first know the enabled state in the background page,
so set the icon there immediately.
|
|
This tidies up some logic that was showing its age.
|
|
Use port for frames
|
|
|
|
|
|
|
|
|
|
Now that we've moved Frame.init() back to before checkIfEnabledForUrl,
there's no longer a need to check that frameId has been initialised. It
must have been.
|
|
|
|
|
|
The intention is to move checkIfEnabledForUrl to the frames port. That
needs to run pre domReady, so first -- here -- we separate the two
ports.
|
|
We treat the top frame specially (because it always has a frameId of 0).
See point "Two" in this comment:
- https://github.com/philc/vimium/pull/2053#issuecomment-196707223
|
|
We never unregister the main/top frame. If the tab is navigating to
another page, then there'll be a new top frame (with the same Id) along
soon. If the tab is closing, then we'll tidy up in the
chrome.tabs.onRemoved listener, below. This approach avoids a
dependency on the order in which register and unregister events happens.
See comment in #2053.
|
|
Tweaks, plus... Reinstate deletion of two cache entries on tab close.
|
|
|
|
Use `onConnect()`, the `domReady` port and `onDisconnect()` to track
the frames within a tab.
|
|
... they were in the wrong place (and were being run twice).
|
|
This code has been written to test both hints modes, however we were
actually only testing one of them!
|
|
When the scrollers `activatedElement` isn't scrollable, we currently
search up the DOM tree for the next scrollable thing, and stop at
`document.body`. However, it can be that that isn't scrollable.
When that happens, this commit searches for a scrollable element in the
same way as it does when the frame initially loads. This makes it
possible to restart scrolling on pages like this one:
- http://redux.js.org/docs/basics/UsageWithReact.html
after clicking one of index links.
Inspired by example posted by @marlun in #425.
|
|
We were using the class name exclusionRemoveButton for the `td`
containing the button to remove exclusion rules on the options page.
Because of this, we were (correctly) picking up the button itself as
clickable, but incorrectly picking up also its enclosing `td` (which
isn't actually clickable at all). The effect was to always have two
hint labels over the remove button.
This was happening simply because we have the text "button" in the class
name. So, here, we just rename the classes.
|
|
Add tests in various areas...
|
|
- key handling
- filtered hints - scoring
- filtered hints - tab
- link hints - changing mode
Also, correct the argument ordering in several assert.equal() calls.
|
|
This adds tests for a couple of properties that are required of alphabet
hint strings.
|
|
Oversight from #2022.
|
|
Fix focus issue with UI components (#2038)
|
|
|
|
- map abc insertMode
- no longer spam dev console
|
|
Problem:
- `?`, `o`, `Esc`, `Esc` leaves the focus in the (invisible) help dialog
frame, rendering Vimium broken.
Since we do
@iframeElement.focus()
when we activate a UI component, here we do
@iframeElement.blur()
when hiding such elements.
Fixes #2038.
|
|
smblott-github/init-ui-components-only-when-enabled
Do not initialise UI components when disabled.
|
|
We can remove these listeners once we're done.
|
|
|
|
|
|
|
|
This addresses the potential race condition mentioned in this commit
record (3542db7b6c322d803c263db641ae0b02327447ca) and in #2033.
In non-top frames, wait until documentReady before sending the message
to initialise the Vomnibar. This cannot be before preDomReady in the
main frame, right?
|
|
HUD: Initialize only when the frame receives the focus and Vimium is enabled.
Vomnibar: Initialize in the top frame when Vimium is enabled in *any* frame.
Warning: There may be a race condition here. Specifically, if Vimium
is disabled in the main/top frame (T) but enabled in another frame (A), then the
initialisation could happen in frame A before frame T is listening, so
frame T would miss the initialization message (which is only sent once).
Message listeners are installed early (and probably installed first in
the main/top frame), and the `isEnabledForUrl` messaging takes some
time, so perhaps it's OK. But it *is* a race condition.
Fixes #1838.
|
|
|
|
`7gj` should be `1j`.
Also, with:
map ab SOMETHING
`7aab` should be `1ab`.
Replacement for 7774beb6643c0d905f9caba4345453790af948ad.
|
|
This reverts commit 7774beb6643c0d905f9caba4345453790af948ad.
Reverting this. It can be done better (and capture some other incorrect
cases).
|
|
With #2022, we can now implement normal-mode key-handling tests.
Writing these tests uncovered the bug behind 7774beb6643c0d905f9caba4345453790af948ad.
|
|
E.g. `7gj` should be `1j`; currently it's `7j`.
|
|
Resize page icons to 128x128.
|
|
Fixes #2035.
|
|
Keep 300x300 copies of the page icons, preparatory to resizing them to
fix #2035.
|
|
|
|
|
|
|
|
|
|
|
|
This is a no-op.
|
|
This generalises the mechanism by which commands are always run in the
tab's main/top frame. Currently, that's just the Vomnibar.
This is a precursor to moving other UI components to the main/top frame.
It should be fairly trivial to move the help page to the main frame.
The HUD might be trickier.
Mention: @mrmr1993.
|