| Age | Commit message (Collapse) | Author | 
|---|
|  | Updating URLs to use HTTPS provides greater privacy and reduces the
potential of having content modified whilst in transit (as it happening
more and more by ISPs, networks, state actors etc).
These URLs themselves have been tested and confirmed to work over HTTPS. | 
|  | @mrmr1993: This is trivial fix for Firefox, so it doesn't warrant a PR.
I'll mention you just to keep you up to date on commits like this,
though. | 
|  |  | 
|  | event.keyCode` is depricated:
  - https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode | 
|  |  | 
|  |  | 
|  |  | 
|  | This reverts commit d00345f45b5b3e56970237799c69808527e91919.
This is not (and will not be) supported by Firefox. | 
|  | For textareas, we still want line breaks, otherwise we would use an
input. Chrome (incorrectly) renders newlines in `white-space: nowrap`
as line breaks; however, firefox collapses the newlines into horizontal
whitespace.
`white-space: pre` is spec'd as intended, and works correctly in Chrome
and FF. | 
|  | Fixes #2454.
Because `Utils` wasn't available, neither were the `mapkey` mappings. | 
|  |  | 
|  | Makes sure all custom link hint characters defined in settings are lowercase | 
|  |  | 
|  | This floats the "5 Matches" text in the find-mode HUD to the right.
This looks nicer, because the "5 Matches" text doesn't move as you type.
As it happens, it also fixes an issue which arose a few months ago (for
unknown reasons) with the positioning of the cursor in find mode.  The
cursor position was becoming "jammed" after the first character as you
type. | 
|  |  | 
|  | 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.) | 
|  |  | 
|  | This is one approach to fixing #2277 properly.  (Currently there's a
temporary fix in place.)
This uses HTML5 imports in place of the content-script loader.
This is better than the current "fix" because content scripts are only
listed in one place two places (as opposed to six).
It's worse than the previous content-script loader, though, in that
content scripts must be listed in two places, instead of one.
Fixes #2277. | 
|  | Follow on from 8601edd71e74ba522e32658309cb2e7acca8aeeb. | 
|  | Scripts loaded via the content-script loader previously were loaded
synchronously.  In recent versions of Chrome, they now seem to be loaded
asynchrnously, which causes errors.
This is a temporary commit to keep master healthy until I (or somebody)
figures out properly what is going on.
It is expected to be reverted in due course. | 
|  |  | 
|  | Do the following:
- `b`, `Tab`
The Vomnibar crashes.  The problem is that we're advancing the selection
even though there are no suggestions available.
Here, we require there to be a suggestion or suggestions before
advancing the selection. | 
|  |  | 
|  |  | 
|  | 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. | 
|  | 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. | 
|  |  | 
|  |  | 
|  |  | 
|  | 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. | 
|  | 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. | 
|  | 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. | 
|  | 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.) | 
|  | 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. | 
|  | 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. | 
|  | Replaces #2037. | 
|  |  | 
|  |  | 
|  | 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. | 
|  |  | 
|  | When the help dialog UI component has been created but subsequently
hidden, `gf` was nevertheless selecting it. | 
|  |  | 
|  | 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. | 
|  | 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. | 
|  | 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. | 
|  | In the previous commits, I omitted to actually check that the help
dialog wasn't closing on the options page.
I should be good now. |