Simon Lydell [Sun, 7 Sep 2014 17:42:20 +0000 (19:42 +0200)]
Improve coding style
- Almost all code is now wrapped at 80 chars, except a few special cases
such as the `commands = [...]` block in commands.coffee. I didn’t
bother to go through help.coffee and window-utils.coffee too much
since they need rewrites anyway.
- Consistent use of parenthesis when calling functions.
- Consistent use of single quotes over double quotes.
- Consistent spacing.
- Removed unused or unnecessary code.
- Refactored unload.coffee into unloader.coffee, which should be easier
to understand.
- Comments are now full sentences.
- This also fixes a few very minor bugs.
I’ve deliberately left out mode-hints/{hints,marker}.coffee to avoid
large merge conflicts with #330.
Simon Lydell [Wed, 13 Aug 2014 19:38:36 +0000 (21:38 +0200)]
Fix #366: Allow autofocus when switching back to a tab
If a text input is focused and you switch to another window or tab
Firefox blurs the text input. When you switch back to the tab, Firefox
automatically focuses the text input again. Those focus events should be
allowed.
Kambfhase [Sat, 2 Aug 2014 21:23:59 +0000 (23:23 +0200)]
updates german locale
Localised some more UI strings to german. However, some descriptions are
still in english and not all translations are displayed. The latter will
be investigated separately.
Simon Lydell [Sun, 27 Jul 2014 10:33:52 +0000 (12:33 +0200)]
Fix #103: Make image zoom toggle keyboard accessible
When navigating directly to an image, and the image does not fit the
screen, it is re-sized so it does. The mouse cursor becomes a magnifying
glass when hovering the image. By clicking you can toggle between native
and re-sized.
As discussed in #355, to keep things simple we now make such images
markable. Using the default mappings and hintchars, the shortcut to
toggle zoom then becomes 'ff'.
This commit is based on #104 by @LordJZ.
Example image:
<http://upload.wikimedia.org/wikipedia/commons/e/e2/Rain_ot_ocean_beach.jpg>
Simon Lydell [Thu, 19 Jun 2014 21:17:54 +0000 (23:17 +0200)]
Only allow focus events immediately after an interaction
Replace the autofocus prevention with suppressing _all_ focus events
that didn’t happen directly after an interaction (keypress or click)
with the page.
Strictly speaking, autofocus may only happen during page load, which
means that we should only prevent focus events during page load.
However, it is very difficult to reliably determine when the page load
ends. Moreover, a page may load very slowly. Then it is likely that the
user tries to focus something before the page has loaded fully.
Therefore focus events that aren’t reasonably close to a user
interaction (click or key press) are blurred (regardless of whether the
page is loaded or not -- but that isn’t so bad: if the user doesn’t like
autofocus, he doesn’t like any automatic focusing, right? This is
actually useful on devdocs.io). There is a slight risk that the user
presses a key just before an autofocus, causing it not to be blurred,
but that’s not likely. Lastly, the autofocus prevention is restricted to
`<input>` elements, since only such elements are commonly autofocused.
Many sites have buttons which inserts a `<textarea>` when clicked (which
might take up to a second) and then focuses the `<textarea>`. Such focus
events should _not_ be blurred.
Simon Lydell [Sun, 15 Jun 2014 14:10:52 +0000 (16:10 +0200)]
Improve find mode. Fix #342. Better Esc handling.
Previously, find mode only worked if you used VimFx's shortcuts to enter
it. If you opened the find bar some other way, you weren't able to end
the search using Enter, and the n/N commands wouldn't repeat what you
just searched for. Now, find mode is entered as soon as the findbar
input gets focused, no matter how it was focused. Find mode is also
exited as soon as the findbar input is blurred. Previously, if you
happened to unfocus the findbar without using Esc or Enter, such as
clicking or tabbing away, then you'd still be in find mode, making all
keypresses focus the findbar input rather than activate commands.
If the active element is editable during a keypress we used to pass that
keypress along to the browser -- regardless of the current mode --
instead of activating commands. The findbar input is also an editable
element, but when it is focused we want Enter to close the findbar.
Therefore we used to not pass along Enter to the browser. If the user
mapped Enter to a command, that meant that it would be impossible to
press enter in an input to type a newline, submit a search query, etc.
Now, we only use this automatic insert mode in normal mode instead.
The above also fixed another problem. We used to always pass Esc to the
browser in normal mode, even if Esc is mapped to a command. Now, that is
not done if we’re blurring an element. That makes it possible to blur an
input inside a custom dialog without closing it (Esc almost always
closes custom dialogs). This makes it possible to use devdocs.io with
VimFx, which was very difficult before.
> - Only `<a>` elements with a `href` attribute should be matched, since
> HTML5 allows `<a>` elements to omit `href`:
>
> > If the a element has no href attribute, then the element represents
> > a placeholder for where a link might otherwise have been placed, if
> > it had been relevant, consisting of just the element's contents.
>
> Reference:
> <http://developers.whatwg.org/text-level-semantics.html#the-a-element>
That’s the spec. In the reality, people use all sorts of weird markup.
Some sites (such as StackExchange sites) leave out the `href` property
and use the anchor as a JavaScript-powered button (instead of just using
the `button` element).
This commit reverts the change to link matching in be94b559b. A side
effect is that sites using links without `href` in compliance with the
spec will get extranous markers for those links. It’s better to show too
many markers than too few, though.
Simon Lydell [Sun, 1 Jun 2014 18:59:35 +0000 (20:59 +0200)]
Fix: Autofocus prevention got stuck by navigating the history
Either going forward and backward in the history, or using
`history.pushState()` caused the autofocus prevention to get stuck,
making it impossible to focus inputs.
Simon Lydell [Sun, 25 May 2014 20:15:41 +0000 (22:15 +0200)]
Raise the z-indexes used to trump youtube
Youtube uses 1999999999 as z-index for its top bar, which is a lot
higher than VimFx used for the help dialog and markers. This caused the
top bar to overlap the help dialog, and, more importantly, the markers,
making it impossible to see the marker for the search box, for example.
This commit raises VimFx’s z-indexes to trump Youtube.
Simon Lydell [Sun, 25 May 2014 19:20:56 +0000 (21:20 +0200)]
Fix #309: Autofocus prevention is broken
Autofocus was broken by some Firefox update, possibly version 29. This
commit fixes it again. It also fixes a bug where autofocus was prevented
even on blacklisted sites, and cleans the code a bit.
Simon Lydell [Fri, 16 May 2014 18:49:38 +0000 (20:49 +0200)]
Slightly improve markable element matching
- Only `<a>` elements with a `href` attribute should be matched, since
HTML5 allows `<a>` elements to omit `href`:
> If the a element has no href attribute, then the element represents
> a placeholder for where a link might otherwise have been placed, if
> it had been relevant, consisting of just the element's contents.
- Elements with the `tabindex` attribute should be matched, but not
`tabindex=-1`, which means explicitly saying that the element should
_not_ be focusable.
Simon Lydell [Fri, 16 May 2014 18:42:31 +0000 (20:42 +0200)]
Let the Esc command close tab groups
Since commit 1fd30eca9 makes opening the tab groups view (ctrl-shift-e)
about the same as focusing a text input (passing all key strokes to the
browser), the Esc command must be able to exit from it.
Simon Lydell [Fri, 16 May 2014 18:26:16 +0000 (20:26 +0200)]
Fix #280: Use `[rel]` for prev/next link matching
The standard way of marking up the previous or next page of a series is
to use a `<link>` or `<a>` element with a `rel` attribute.
We don’t bother with `<link>`s since the commands are substitutes for
clicking a visible element. (And at least in my experience, they’re not
commonly used.) Moreover, if there’s a `<link>` with a `rel` attribute,
there’s likely a corresponding `<a>`, too.
We first try to find a nicely marked up link, then we fall back on
pattern matching of the text contents of the links.
The spec on the `rel` attribute:
<http://www.w3.org/TR/html5/links.html#linkTypes>
How Google handles it:
<https://support.google.com/webmasters/answer/1663744?hl=en>
Simon Lydell [Tue, 13 May 2014 19:40:54 +0000 (21:40 +0200)]
Fix #318: Support Tab Groups
Just like when a text input is focused, send all keys to the browser.
This allows you to type the name of a tab to select it. Moreover,
commands doesn’t make sense when Tab Groups is opened, since they affect
the current tab, which is hidden _behind_ Tab Groups, out of view!
git://git.gir.st / VimFx.git / log