| Age | Commit message (Collapse) | Author |
|---|
|
When we open the help dialog, scroll it, close it then open it again,
the scroller loses track of the scrollable element. This is because the
scroller is still referenceing the old scrollable content as its
"activated element".
Here, we click the dialog element to get the scroller back in sync.
(Note: This is a more general problem which we need to look into.)
|
|
Apart from looking better (ie. symmetric), this also ensures that the
help dialog does not overlap the footer on the options page (which is
ugly).
|
|
This reverts commit f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125.
Conflicts:
content_scripts/vimium.css
Revert previous change to help-dialog styling.
|
|
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.
|
|
The raw query is not used by this message handler, so don't send it.
|
|
Previously, we were transferring a "transferable event" from the HUD UI
component to the content script (when find mode exits).
In addition to being unnecessary, this was triggering a warning in the
console because we were reading *all* of the events keys, including one
which triggers a "this is being deprecated" warning.
The approach here is simpler, transfers less data and avoids triggering
the warning.
|
|
When the implementation of windowIsFocused() changed, the tests started
failing.
(It's not clear how I didn't spot this sooner. I've run the tests
countless times - and they passed - since that change was made.
|
|
If the help dialog loses the focus and closes, then we abandon any HUD
which is being displayed. This ensures that - when the help dialog is
reopenned - we're not displaying an old, out-of-date HUD message.
|
|
Previously, requests (like opening the Vomnibar) would be silently
discarded if they arrive before the document is ready. Here, we queue
them instead.
|
|
This replaces c01d7eea8675f9a7d84999777e8de72244d687b6.
All UI components require the document to be ready. So, here the
constructor waits for DomUtils.documentReady(). The diff looks big, but
mainly it's a result of changes in indentation in the constructor and in
hide().
Also, hide() now uses @postMessage() to post a null message. This
forces hide to use @iframePort.use(), which ensures that hide()s cannot
overtake activate()s.
This continues #2100.
|
|
This reverts commit c01d7eea8675f9a7d84999777e8de72244d687b6.
Preparatory to implementing an alternative approach.
|
|
|
|
Move help dialog to top frame
|
|
The Vomnibar isn't needed on most tabs, so don't init it.
I cannot detect any sluggishness as a result of this.
|
|
This avoids initializing around 15 (almost all unused) HUDs on sites
like GMail and Google inbox.
Because the HUD is small, there is not noticable flicker.
|
|
Replaces #2037.
|
|
|
|
In 5c3e4bda2968486e23f8cc3410e776de67fec849, I omitted to observe that
we need to know whether the window has the focus *before* the DOM is
ready when checking whether Vimium is enabled.
This fixes that.
|
|
Simplify javascript: URLs in vomnibar.
|
|
Rework ui component focus handling
|
|
This fixes two issues:
- We cannot set windowHasFocus until the DOM is ready (because
document.hasFocus isn't set until then.
- We should use windowhasFocus in prefernce to document.hasFocus
because, for framesets, document.hasFocus is true for both the
frameset and a focused contained frame.
|
|
|
|
Remove special-purpose code from `gf`.
Instead, register the help dialog frame when it launches, and unregister
it when it's hidden.
This way, when the helpd-dialog frame is hidden, it simply isn't
available for `gf` and for link hints.
|
|
We do not need "displayUrl", we can re-use "shortUrl" instead. It does
what we need already.
|
|
|
|
We only match the text "javascript:...".
The affects only the bookmark completer.
|
|
|
|
When the help dialog UI component has been created but subsequently
hidden, `gf` was nevertheless selecting it.
|
|
|
|
|
|
It interferes with the HUD's timing.
|
|
|
|
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.
|
|
|
|
Rework UI component init sequence.
|
|
Add <c-y> and <c-e> for visual mode.
|
|
In testing global link hints, it seems that UI components can be opened
before they're actually ready, and Vimium hangs with a broken UI
component displayed. This issue seems to be in 1.54 too.
It's not clear what's causing this -- and it's hard to reproduce
systematically. However, it only seems to happen on navigation.
Therefore, it seems likely that there is an issue with the
initialization sequence.
Here, we wait for:
- the DOM content to be ready, and
- the port to be provided
before registering the UI component as ready.
|
|
Fixes #2092.
|
|
Similarly to the previous commit: 454f5272c71388c53665d7505aa6832566284e2b.
This is intended to mitigate some CSP violations we're seeing. In some
circumstances - as yet not fully pinned down - messages to the HUD
trigger CSP violations. Until we track that down, we move all HUD
operations (in link hints) to the end of their execution slice. So, if
HUD operations fail, then they won't affect any other operation.
The error message for offending HUD operations is:
ui_component.js:55:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided
('chrome-extension://hiihfcebjbnoniicphblpiekhfmbdmog') does not match
the recipient window's origin ('null').
|
|
This is part of an effort (as yet incomplete) to track down some CSP
violations we're getting, in this case related to global link hints.
Prior to this, we were seeing CSP violations when accessing the window
subsequently to collecting the hints, specifically when accessing
window.scrollX/Y. Here, we collect the window position immediately,
when initially harvesting the hints.
|
|
Assume there is an existing range selection.
Consider `v`, `Escape`. Previously, this had the side effect of
clearing the selection. That behaviour seems odd and wrong.
Here, we retain the selection if there was an existing range selection
when visual mode was launched.
Arguably, this removes a "feature" whereby `v`, `Escape` clears the
selection. Here, we take it that the oddity above outweighs the loss of
this arguably unintentional "feature".
|
|
This applies to when find mode is launched.
When the text was empty (which is always), we were triggering a console
error message (selection range isn't in document). However, when the
text is empty, we don't actually need to add it to the input. So, here
we don't.
|
|
Here's the trade off... We either *always* initialize the help dialog in
every frame of every tab, or we initialize it only when needed.
The help dialog is rarely used by anybody except beginners, so the
latter seems like the better approach. However, on busy/slow loading
pages, the help dialog can fail to load on page start up. (We need to
fix this, but I don't know how right now). In the meantime, the better
compromise seems to be to initialize the help dialog only when needed.
This was the status quo prior to 6e12e005a4261711583571be23018481a4a23230
and 09e119db8d8c3ad2077ac509f73fefb76a08fac0.
|
|
|
|
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.
|
|
Show "javascript:" URLs as "javascript:...".
Fixes #961.
|
|
1. Do not initialize UI components until the DOm is ready.
2. Do not register UI components as ready (specifically the HUD) until
the full initialization sequence is complete.
This goes some way towards fixing the issue described in this comment:
https://github.com/philc/vimium/issues/2081#issuecomment-205758102
It relates to link-hints mode hanging when launched during a navigation.
This problem exists in 1.54, but emerged during testing of global link
hints.
"Some way toeards fixing..." because it is still possible to trigger
issues.
|
|
Two minor tweaks:
1. Do not use ".indexOf()" three times for each comparison; do it just
once.
2. Check the common case (no match) first.
These are very minor performance tweaks; but, with global link hints,
we pay this cost n times (for n frames).
|
