| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This mimics the look of Google Inbox or Github.
The background colour is from Google Inbox, Github uses a slightly
lighter colour.
|
|
It's not clear when -- possibly when we moved the help dialog to an
iframe -- the links at the bottom of the help dialog stopped working.
Here, we reinstate them by opening the referenced page in a new tab.
This is consistent with the behaviour of the links at the top of the
help dialog.
Also, the "please review us" link now points to the "reviews" tab on the
Chrome store.
|
|
Prime focus input on the Vimium options page.
|
|
|
|
This is a bit of a hack, and pertains to focusInput (`gf`).
The problem... On the options page, there are *lots* of inputs
(specifically, for every exclusion rule there are two inputs). This
makes `gf` almost unusable. It's impossibly to `Tab` through them all.
Here, on the options page, we prime the pre-selected input to be the
key-mappings input:
- arguably, this is the most frequently used input, and
- other inputs (such as custom search engines) are just one `Tab` away.
|
|
This effectively reverts 4b564e8517dd3415cb8e2209ce019fa024e88770.
Reinstate pre-initialization of the Vomnibar.
Without pre-initialization, there is a small but noticable sluggishness
the first time the Vomnibar is opened.
|
|
Previously, you could blur the help dialog on the options page (to read
and type command names).
With the reinstated help-dialog styling (whereby the help-dialog iframe
extends across the entire window), this doesn't make sense. So it's
removed.
|
|
This reverts commit 86470f13d853b33cda8cb006ae24aeb2dcec0c9c.
|
|
This reverts commit d95f811a8bc32803bfaec69e4853c5d48500905e.
|
|
|
|
We make the help dialog iframe cover most of the height of the window,
but only be as wide as it needs to be.
Like this, the user can click to the side of the dialog (on the options
page) to enter bindings in the custom ley mapping input, with the help
dialog open.
|
|
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.
|
|
|
