| Age | Commit message (Collapse) | Author |
|---|
|
Inject user css into all frames
|
|
This fixes #2594.
|
|
|
|
|
|
|
|
|
|
This also stops the content scripts from being injected into each frame
on reload (in Firefox only). They do not successfully connect to the
background page, and it causes considerable lag, so we lose nothing by
doing this.
|
|
The problem is that Firefox balks at function properties within the
response sent via `postMessage` (whereas Chrome does not).
A concise and safe way to sanitize the response is to convert it to JSON
and back.
Fixes #2576.
|
|
Firefox baulks at "about:newtab" in createTab (but seems happy with no
URL specified). Chrome is also happy with no URL specified.
(Does this mean that we don't need "about:newtab" ANYWHERE in the code
base? Could Settings.defaults.newTabUrl just be ""?)
Mention @mrmr1993.
|
|
|
|
The documentation suggests that 'highlighted' is equivalent to
'selected'. However, multiple tabs can be highlighted in a window -- in
fact, everywhere 'selected' was used, we wanted the unique active tab.
|
|
|
|
|
|
|
|
This means that we get the new tabs in the same order as they are
specified in the key mapping.
|
|
Example:
map a createTab http://edition.cnn.com/ http://www.bbc.co.uk/news
which creates two new tabs, but preloaded with these specific URLs.
`2a` creates four new tabs, two copies of each.
Limitation:
- We cannot control the order of the tabs, so we might get CNN then BBC,
or BBC then CNN. This happens because command options are stored in
an object, and we cannot control the order of the keys.
Also, with:
map a createTab http://www.bbc.co.uk/news http://www.bbc.co.uk/news
we only get one new tab (same reason as above).
|
|
Previously, the dynamic HTML for the help dialog was generated on the
background page. The HTML itself was tangled in with program logic.
Here, we move all of the HTML to HTML5 templates; also, we build the
help-dialog contents in the help dialog itself, not on the background
page.
Note: #2368 is included here too.
(Background: I'm trying to clean up some of the command and help-dialog
logic in preparation for addressing the issue of how to document command
options, see #2319.)
|
|
Comminication by the frame's port is faster, and no response is sent.
|
|
Currently, all new releases trigger a notification.
This changes that behaviour such that if the previous and current
releases have the same major and minor release numbers, then no
notification is shown.
This allows us to push bug-fix and minor releases without bugging the
user.
|
|
This adds advanced options for toggleMuteTab.
Examples:
map X toggleMuteTab all
map Y toggleMuteTab other
In the first case, all audible, unmuted tabs are muted; otherwise all
muted tabs are unmuted.
The second case is the same, except that the current tab is excluded
from consideration.
Follow on from #2269.
|
|
|
|
|
|
|
|
|
|
Sometimes, link-hints mode fails to launch. See Issue 1 from this post:
https://github.com/philc/vimium/issues/2081#issuecomment-210980903.
Here's a reproducible case:
- visit twitter
- using the vomnibar, visit any other page (in the same tab)
- hit `f` - the link hints fail to load.
What's happening is that the unregister/register frame messages for the
main/top frame arrive in the wrong order (first register, then
unregister). Because these both have the same frame Id, the effect is
that the main/top frame ends up not registered. So there are no
registered frames, so link hints mode doesn't launch.
Only the main/top frame has a re-usable frameId (`0`). All other frames
receive a unique frame Id (which is never re-used).
Here, we just never unregister the main/top frame. That way, it doesn't
matter which order the register/unregister messages arrive in. If the
tab is navigating to a new page, then there'll be a new main/top frame
along soon. If the tab is closing, then we tidy up in the
`chrome.tabs.onRemoved` handler.
|
|
I seems that we cannot rely upon either the "unload" event in the
content script or the port's onDisconnect handler there to unregister
frames.
To see this, go to a frame-busy page like this one:
- https://www.theguardian.com/technology/2016/apr/26/apple-iphone-first-revenue-decline-13-years
and then navigate to any other simple page (in the same tab). Navigate
back and forward with `H` and `L`.
If you watch frames registering anf unregistering, almost all of the
frames from the frame-busy page do not unregister.
Here, we unregister frames on onDisconnect in the background page too.
It is possible that this is the source of the problem mentioned as point
1 in this comment:
- https://github.com/philc/vimium/issues/2081#issuecomment-210980903
And for which #2116 is a workaround.
|
|
|
|
It's pretty undiscoverable that you can click command names to yank
them. So, this adds a tip to the bottom of the help dialog.
Also, change the cursor to a pointer when hovering over command names.
|
|
The commands names (in the help dialog) look nicer in italics. They
also format better that way.
|
|
|
|
This needs more work.
|
|
|
|
|
|
Previously, we had two different approaches. This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory. This seems to be the right thing to do. Caching the CSS in
memory consumes a small amount of memory. However, it can only speed up
the fastest loads. It cannot speed up the first load -- which is likely
the one that matters most. So caching the CSS in memory seems to make
little sense.
|
|
This reverts commit 0a49cc45732175c65651b5f054c677d6c42a28c0.
|
|
Previously, we had two different approaches. This seems like a simpler
approach.
We simply cache the Vimium CSS in chrome.storage.local (in the
background page) and fetch it from there (in UI components).
There is also a minor change in the we no longer cache the CSS in
memory. This seems to be the right thing to do. Caching the CSS in
memory consumes a small amount of memory. However, it can only speed up
the fastest loads. It cannot speed up the first load -- which is likely
the one that matters most. So caching the CSS in memory seems to make
little sense.
|
|
|
|
Reinstate test removed incorrectly in d1c230cabb051a5429242c98e67d37b65edc58b8.
|
|
When distributing hint descriptors, do not post a frame's own hint
descriptors back to the frame itself. It already has them.
With regard to the message-passing cost only, this represents a speedup
of approximately 3/2 for link-busy sites like reddit -- several tens of
milliseconds for me. There are other costs too (such as processing the
hint descriptors) bu these are not affected.
|
|
|
|
|
|
- Unregister frames with the background-page hint coordinator.
- Better page cleanup in the content scripts.
- Require documentReady before harvesting hints.
There is still an issue in some cases when link-hints are activated as a
page is transitioning, but that problem case seems to have existed in
1.54. I'll continue to investigate.
|
|
It seems we cannot rely on the port being disconnected to unregister a
frame. So we need to unregister it on "unload".
|
|
There's other stuff (ports, frameIds) in @tabState[tabId] that we don't
need in the front end. Here, we only send the three properties which we
do need.
|
|
This is not at all satisfactory.
I've seen cases where global link hints hangs, apparently because we do
not hear back from a frame. The issue is repeatable when it happens,
but not repeatable in general (if you reload the page, then it goes
away). This suggests that there may be something fundamentally wrong
with the global link-hints logic. However, what?
In the interim, this adds a timer to trigger link-hints mode activation
with whataver hints we do have after a short period of time.
Ideally, we'll be able to get rid of this soon.
|
|
If we lose contact with a frame (it's goine away) while still awaiting
hints from that frame, then post a dummy/empty list of hints instead.
This seems very unlikely to come up, but we should guard against it
anyway.
We use "nextTick()" so that we finish sending the current message
before sending the dummy hints.
|
|
This is experimental, and may be reverted.
I suspect that the special treatment of the top frame may actually be
causing problems for global link hints (rather than solving them!).
|
|
The check that an element as an href (for certain hint modes) can be
done earlier, thereby avoid the need to pass that information between
frames.
|
|
We take a copy of the frame Ids and ports at the point which link-hints
mode is launched, and use that subsequently. Therefore, a newly created
frame cannot cause the hint coordinator to become confused.
Also: add debugging code.
|
|
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.
|
