| Age | Commit message (Collapse) | Author | 
|---|
|  | If the link's value is not a string, then the previous version of this
fails.  The new test will be false for such links. | 
|  | adding single left/right angle quotation marks"
This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff.
This reverts #2117.
This breaks next/prev on Reddit (it chooses a different link).
Reddit is an important site, so we should unwind this for now.
Mention @sco-tt. | 
|  | Fix UI-component initialization issues (maybe). | 
|  |  | 
|  |  | 
|  | next/prev links | 
|  | This fixes some UI component initialization issues.  It's a long
story...
The problem.
- Go to this page: http://www.thejournal.ie/seanad-election-results-2016-2737768-Apr2016/
- Click one of the links from the "Most Popular" box on the right.
- Navigate back (`H`) and, as the original page is loading, activate the Vomnibar.
In 1.54 this renders Vimium unusable.  In `master` this renders the
Vomnibar unsable, but the rest of Vimium usable.
It seems the source of the issue is that we're initializing UI
components too soon.  We need to wait until the `readyState` is
"complete".
With this PR:
- The Vomnibar is initialised when the `readyState` is "complete" (in
  the top frame only, and only if Vimium is enabled).  Requests arriving
  prior to then are silently discarded.
- The HUD is also initialized only when the `readyState` is "complete";
  however, requests arriving before then are queued.  So, if the user
  immediately enters insert mode, then the "Insert mode" indicator will
  eventually be displayed.
- The help dialog silently discards requests until the `readyState` is
  "complete.
I'm posting this as a PR because:
1. It needs some visibility.
2. With this, if the `readyState` *never* reaches "complete", then the
   Vomnibar would be unusable.  And that's pretty serious. | 
|  | There are circumstances when we hav two (identical) vimiumFlash elements
displayed: specifically, when using the waitForEnter keyboard blocker.
So, we should use a class (rather than an id) to style the flash
element. | 
|  | left/right angle quotation marks | 
|  | Modernize help dialog styling | 
|  | On the help dialog, use the same blue of the "Vim" of "Vimium" for
links. | 
|  |  | 
|  | If we're not using the previous font for other links on the help dialog,
then it doesn't make sense to use that font for command names either. | 
|  |  | 
|  |  | 
|  |  | 
|  | Make zoomable images clickable: e.g. http://i.imgur.com/LdCeLlk.jpg/. | 
|  | Re-order the tests such that we don't even do the scoring if there are
no query (search) terms.
This might (very) marginally speed up link-hints launch. | 
|  | Following 029741ea2d93031f0c9d5e57ba9cf75546976798 (which seemed
trivial), I forgot to check the tests (which were in fact broken, and
correctly broken).
If there is no link-text key queue, then *all* links should match. | 
|  | Only keep non-empty link words.  Empty link words cannot be matched, and
leading empty link words disrupt the scoring of matches at the start of
the text.
E.g. "9 new messages" with a query "new" should score as a match at the
start of the text. | 
|  |  | 
|  | Make the font size (and color) match those used in the footer. | 
|  |  | 
|  | 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. | 
|  | - Style the links at the top the same as those at the bottom (re.
  colour).
- Fix HTML indentation. | 
|  | The commands names (in the help dialog) look nicer in italics.  They
also format better that way. | 
|  | Use margins to centre the help dialog.  This works better on narrow
windows, and seems to produce a balanced dialog in a variety of cases. | 
|  | This gest the centring calculation correct.
Also, remove the shadow; it's not visible. | 
|  |  | 
|  | This needs more work. | 
|  |  | 
|  |  | 
|  |  | 
|  | This mimics the look of Google Inbox or Github.
The background colour is from Google Inbox, Github uses a slightly
lighter colour. | 
|  |  | 
|  | 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. | 
|  | 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. | 
|  | 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. | 
|  | 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. |