Simon Lydell [Sat, 17 Jan 2015 23:22:53 +0000 (00:22 +0100)]
Fix #249: Support other keyboard layouts than en-US
This uses lydell/vim-like-key-notation. The old notation is supported too, for
backwards compatibility: Old customizations still work, and continue to work if
the user downgrades.
Simon Lydell [Sat, 17 Jan 2015 16:38:06 +0000 (17:38 +0100)]
Add default shortcuts to new commands
- Toggle pin tab: gp (go pin)
- Duplicate tab: yt (yank tab, same as Vimium)
- Close tabs to the right: gx$ (like g$ (go to last tab), but with an x in it as
in "remove it!")
- Close other tabs: gxa (similar to gx$, go close tabs around the current)
Simon Lydell [Sat, 17 Jan 2015 16:19:25 +0000 (17:19 +0100)]
Fix #382: Support 'selection' clipboard
Supersedes #397. The p and P commands now use either the selection clipboard or
the global clipboard, whichever was used last or is supported by the OS. This is
a slightly breaking change since we used to only use the global clipboard, but
I've used this new behavior and it doesn't bother me. Morever, it is how
Pentadactyl works, and how the built-in `readFromClipboard()` function works.
Simon Lydell [Sat, 6 Dec 2014 22:42:32 +0000 (23:42 +0100)]
Make `require` more like Node.js
- Add support for `module.exports`.
- Add support for npm modules in `require()`. Note the following differences
with Node’s `require()` though:
- Only `require(path)` is supported, not `require.resolve()` or related
`module` properties etc.
- Absolute paths (`/foo/bar.js`) are not supported.
- Only JavaScript files may be required (not JSON files, for example). Paths
must not end with `.js`.
Moreover:
- `module.onShutdown(handler)` is used instead of
`require('unloader').unloader.add(handler)`.
- bootstrap.coffee has been cleaned up. I had a lot of help from looking at
<https://github.com/adblockplus/buildtools/blob/7a305df14bf3d26ff559f06082b87ff7cff4b3b8/bootstrap.js.tmpl>
- `extension/packages/` has been renamed to the more Node-style
`extension/lib/`.
- The huffman module has become its own repository, and is now `npm install`ed.
This change allows users to blacklist only some keys on a website.
These keys are not suppressed and the corresponding VimFx command is not executed.
Blacklist rules can now be of the form `<pattern>##<keyString1>#<keyString2>`.
Existing rules not using this syntax will continue to work.
Simon Lydell [Tue, 30 Sep 2014 19:17:04 +0000 (21:17 +0200)]
Try points one pixel into the elements from the edges
On newyorker.com, `transform: translate3d(0, 0, 0)` is applied on the
content container, to force hardware acceleration. It seems to move
everything a pixel, causing `document.elementFromPoint` to fail at the
edges of elements. This commit no longer looks exactly at the edges of
elements, but one pixel in, which seems to be a safer strategy. (The
marker is still nicely placed exactly on the edge, though.)
Example page:
http://www.newyorker.com/currency-tag/the-virtual-moleskine
Simon Lydell [Tue, 30 Sep 2014 18:51:27 +0000 (20:51 +0200)]
Improve markers for inline line-wrapped elements
If an inline line-wrapped element starts with a line break, its first
rect will have an area of almost zero. The marker used to end up on that
rect, seemingly on the line before the actual link, which was very
confusing. Now, such small areas are rounded to zero, and all
`visibleRects` that have a zero area are discarded, solving the problem.
An example can be found at the bottom of this page:
http://swrevisited.wordpress.com/esbr-facts/
Simon Lydell [Wed, 10 Sep 2014 19:01:04 +0000 (21:01 +0200)]
Improve marker placement and fix related bug
Before commit 89e1bc4 we used to recursively search the rect of an
element until it found a non-covered point; after that commit we changed
into only checking 6 simple locations of the element, for performance
reasons. However, this meant two problems:
- It was very confusing when markers ended up to the far right of
elements. Sometimes it was difficult to understand which element the
marker actually belonged to. Sometimes a tiny bit of the left side of
an element was covered (possible by a _transparent_ element!) causing
the marker to end up on the right instead, seemingly for no reason.
- Some elements are overlapped by one pixel both on the left and right
side (such as the github pagination links), causing no marker at all
to appear.
The solution is to use the best of both before the referenced commit and
after it. Now we check 3 (instead of 6) simple places: Only the 3 on the
left side. If the place is covered by another element, we try once to
the right of that element. So in total there may be 6 attempts, just as
before.
Author: Simon Lydell <simon.lydell@gmail.com>
Date: Sat Aug 2 16:01:36 2014 +0200
Improve marker generation performance
`getFirstNonCoveredPoint` used to recursively search the rect of an
element until it found a non-covered point. This works well most of the
time, but on some sites (such as prisjakt.se) it took way too much time.
Moreover, this technique required some CSS to be reset in a few special
cases, which is very costly performance-wise. It is also brittle and
makes the code unnecessarily complex.
Lastly, there was a bug in the algorithm that caused uncaught exceptions
sometimes (such as on youtube.com).
Now we use a much simpler approach instead.
`getFirstNonCoveredPoint` tries 6 different points of the element:
If all of those are covered (or are reported as covered because of one
of the CSS special cases we used to reset) then the whole element is
simply considered to be covered. This seems to work really well.
The above means that the markers can now be placed at any of the points
in the above figure.
The result is much faster, simpler and more robust.
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 [Sat, 16 Aug 2014 15:54:35 +0000 (17:54 +0200)]
Enhance marker frame handling
Previously the frame elements themselves were required to get a marker
in order to make markers for any elements inside the frame, which was
pretty confusing. Now all frames visible in the viewport are gone
through to add markers their elements.
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 [Sat, 2 Aug 2014 14:01:36 +0000 (16:01 +0200)]
Improve marker generation performance
`getFirstNonCoveredPoint` used to recursively search the rect of an
element until it found a non-covered point. This works well most of the
time, but on some sites (such as prisjakt.se) it took way too much time.
Moreover, this technique required some CSS to be reset in a few special
cases, which is very costly performance-wise. It is also brittle and
makes the code unnecessarily complex.
Lastly, there was a bug in the algorithm that caused uncaught exceptions
sometimes (such as on youtube.com).
Now we use a much simpler approach instead.
`getFirstNonCoveredPoint` tries 6 different points of the element:
If all of those are covered (or are reported as covered because of one
of the CSS special cases we used to reset) then the whole element is
simply considered to be covered. This seems to work really well.
The above means that the markers can now be placed at any of the points
in the above figure.
The result is much faster, simpler and more robust.
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.
git://git.gir.st / VimFx.git / log