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!
Simon Lydell [Sun, 26 Jan 2014 14:21:07 +0000 (15:21 +0100)]
Refactor follow prev/next links
- Simplified everything.
- Made it more DRY.
- Patterns can include the * and ! wildcards, just like the black list.
- Patterns must match either at the beginning or at the end of the link
text.
- Patterns don’t match in the middle of words. Works with non-English
characters too.
Simon Lydell [Tue, 28 Jan 2014 18:52:29 +0000 (19:52 +0100)]
Improve popup passthrough check performance
Commit 468ed83 sure made the popup passthrough check more robust.
However, querying for all popups (hundreds) and looping them through on
each keypress is not optimal for performance. The solution? Use the best
of both of the old and new passthrough check.
Looking back, the issue with the old event-based passthrough check was
not that passthrough sometimes wasn’t triggered. It was that passthrough
sometimes got stuck, effectively disabling the extension. So it is not
the 'popupshowing' event that is unreliable, it is the 'popuphidden'
event. So we now use the events for toggling passthrough mode, just like
before. But when `popupPassthrough == true`, we don’t trust it. Then we
loop through all popups to see if any of them actually is open. This
means that it is only when a popup (might) be open that we use the more
expensive check, which is a good tradeoff. Even then, you probably won’t
even notice a lag or anything.
git://git.gir.st / VimFx.git / log