| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
The help-dialog UI component was ignoring requests to "hide" when other
frames are focused (because previously it covered the whole screen, and
no other frame could get the focus).
With f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125, the help dialog no longer
covers the whole screen, so it must listen for and react to
"frameFocused" events.
However, the help dialog should not "hide" when the frame that is
focused is itself! This required a little extra plumbing. That
plumbing is helpful, though, because it allows individual UI components
to decide what to do when another frame receives the focus (as opposed
to the previious version, which simply unilaterally sent a "hide"
message).
|
|
Normally, we close the help dialog when the user clicks outside of it.
On the options page, however, the user might want the help dialog open
while they type command names into the key-mappings input.
Therefore, we disable hide-on-click for this specific use case.
This is a rather unfortunate hack. However, #2045 is a serious problem
for an important use case.
Fixes #2045.
|
|
|
|
We were using the class name exclusionRemoveButton for the `td`
containing the button to remove exclusion rules on the options page.
Because of this, we were (correctly) picking up the button itself as
clickable, but incorrectly picking up also its enclosing `td` (which
isn't actually clickable at all). The effect was to always have two
hint labels over the remove button.
This was happening simply because we have the text "button" in the class
name. So, here, we just rename the classes.
|
|
|
|
|
|
|
|
|
|
|
|
Make command names in the help diablog clickable.
|
|
|
|
The styles guide says not to use standalone `@`. So this changes the
occurrences I could find (with sed) to `this`. Occurrences within files
with major outstanding PRs are omitted.
|
|
Clicking on command names in the help dialog copies the command name to
the clipboard. Moreover, command names can be clicked (hence copied)
with link hints.
As a a side effect, any element on any page with the `vimiumClickable`
class becomes clickable. That's zero elements on zero pages, currently.
But there was a PR some time ago where a web developer was looking for a
way to make their elements vimium clickable.
On the negative side, this is pretty undiscoverable. Also, the
`indexOf()` class-name test within a string isn't exactly precise.
|
|
Add install date to logging page.
|
|
This is no longer necessary since the help page is in an iframe.
|
|
|
|
|
|
Oversight from #1958.
|
