| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
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.)
|
|
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 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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
This is no longer necessary since the help page is in an iframe.
|
|
|
|
|
|
|
|
|
|
|
