VimFx v0.17.1

Fix `zF` double clicking on browser elements (#757)

`nsIDOMWindowUtils.dispatchDOMEventViaPresShell()` dispatches
a 'command' event automatically after a 'click' event on XUL pages.
This was causing `zF` to effectively double click on browser elements,
since VimFx also simulates a 'command' event.

Elements which suffers from this double click include but are not
limited to, the new tab button, question mark circles in the preferences
page and buttons created by the add-on sdk.

Update devDependencies

Fix the "URL popup" not appearing when using `zf`

Fix `zF` crashing when devtools open in Firefox 49

 Update it locale (#753)

Refs. #728

VimFx v0.17.0

Update devDependencies

Fix some `require` sorting

Rename l10n.coffee into translate.coffee

Simplify some code by changing `.bind()` into `->`

Replace `@` with `this` when not used as `@keyword`

Remove outdated comment

Ignore counts in Ignore mode

Add some comments and info for commit 5ca124b4d

Dispatch trusted mouse events to content page (#751)

Some DOM APIs need to be called from the handler of a trusted event to
work. `requestFullscreen()` and `document.execCommand('copy')` are
examples of such API.

Before this patch, VimFx dispatched mouse events using
`element.dispatchEvent()` which had the event handlers for the events
running in untrusted context. This behavior prevented hint mode from
full-screening on Youtube and copying clone addresses on Github.

This patch uses XPCOM to dispatch mouse events as trusted events to the
content page.

See also:
https://www.w3.org/TR/uievents/#trusted-events - info from the spec
https://clipboardjs.com/ - before this patch, copying doesn't work

Improve Marks mode UX

- Return to Normal mode if a mark key hasn't been pressed within
  `options.timeout` milliseconds.

- Let `<escape>` return to Normal mode instead of creating or going to a
  mark named `<escape>`. Previously, if the user pressed `<escape>` as
  an attempt to exit Marks mode after accidentally pressing `m`, that
  would indeed exit Marks mode, but it would also set the `<escape>`
  mark. That meant that after that point, the user couldn't exit Marks
  mode using `<escape>` after having pressed `` ` `` without the side
  effect of scrolling to the `<escape>` mark.

- Marks mode has been hidden from the help dialog, in order not to
  clutter it with unnecessary information. While at it, Find mode was
  removed from the help dialog as well, for the same reason. Both modes
  are still available in VimFx's settings page in the Add-ons Manager,
  though.

Fixes #750.

Fix `[data-command]` being `undefined` in help dialog

Make the `?` command and the button _toggle_ help

I've noticed people (including myself, sometimes) unconsciously
expecting both the `?` command and the button to _close_ the Keyboard
Shortcuts dialog if it is already open.

I don't think there's any need complicating the description of the `?`
command and the tooltip of the button to reflect this.

Improve find commands race condition robustness

Possibly related: #749.

Fix some odd formatting in gulpfile.coffee

Fix being unable to scroll the page on some sites

Remove repeated word in a comment

Drastically speed up `find_from_top_of_viewport`

- Don't recurse into children of elements when looking for visible text
  nodes; we'll get to them anyway since we iterate over every element of
  the page.
- Don't bother checking text nodes that we already know are whitespace
  only.

Fixes #747.

Remove trailing whitespace in fr locale

Update zh-CN locale (#745)

Fix some ambiguous/wrong translations.

Update fr locale (#744)

Refs. #728

Prevent accidental command activation after pressing `/`

Update zh-TW locale (#743)

Refs. #728

VimFx v0.16.1

Fix crash in the `zF` command

VimFx v0.16.0

Update devDependencies

Improve nonCoveredPoint checks

- Skip trying to the right of a covering element if that's further to
  the right than the element's rect.

- If the covering element is a parent to the element we're checking,
  don't try looking to the right of the parent. It is _very_ unlikely
  that we'll find the element we're checking there. Instead, try the
  most likely point to be non-covered: The center of the element. This
  needs to be done because of pseudo-elements of the parent element
  which might cover the link partly, likely at the edges. Fixes #742.

Include possibly covered elements for complementary hints

There might be false positives when checking if an element is covered or
not. This commit includes covered elements when switching to
complementary hints (`<c-enter>` in Hints mode), so that you can target
for example links which are only partly covered.

See #742.

Improve the Find next/previous commands

- Finding is asynchronous. This commit makes sure to wait until the
  finding is done before sending notifications (such as "Phrase not
  found"). This makes the notifications more reliable.
- Prevent the find bar from re-opening if there are no matches.
  Fixes #739.

Fix focus handling

When blurring a UI element, we handle that blur after a timeout. If
the UI element was blurred due to focusing a frame element, the focus
events for that frame element occurs _before_ handling the UI blur. That
caused the focusType to be set according to the UI blur, and not
according to the frame focus. This meant that if you had the location
bar focused and clicked inside a text input in a web page, VimFx would
enter and then immediately exit "auto insert mode". This commit fixes
this issue by asking the frame script for the focusType if a 'focus' or
'blur' event is caught in the UI and the active element is the current
`<browser>` (instead of treating `<browser>` as focusType 'none').

Also, since commit fee33fa8, 'focusTypeChange' events are only sent when
_changing_ the focusType of a `vim`, _not_ when trying to set the
focusType to the same value as before. While that's good, it caused a
problem when switching tabs. When switching tabs, 'blur' events occur in
the old tab and (re-)'focus' events occur in the new tab, but no
focusType of any `vim` is necessarily changed. However, one tab might be
in "auto insert mode" while the other isn't, so the button would still
need to be updated. Therefore, this commit sends a 'focusTypeChange'
event when switching tabs.

See #738.

Update es locale (#737)

Refs. #728

Update zh-CN locale (#736)

Refs. #728

Update release procedure docs

VimFx v0.15.1

Update release procedure docs

Update ja locale (#734)

Refs. #728

Improve hints on Twitter

- Removes a useless hint that covered the hint for showing more tweets.
  Thanks to @XrXr for reporting and suggesting a fix. Supersedes and
  closes #732.

- Adds a hint for each tweet, allowing to open it in the
  popup/modal/lightbox thingy.

Improve focusType detection

Inputs focused and blurred inside the Evernote Web Clipper extension's
popup (which is an `<iframe>` injected into the browser UI) were
previously not detected (making it difficult to type into them without
triggering VimFx commands). That was because we have to check if events
really are UI events or not in order to support non-multi-process
Firefox (which expose web page content events to UI code), and
Evernote's elements seem to be indistinguishable from web page content.

This commit simply removes the check for where the event comes from when
looking for focusType changes. Luckily, it doesn't matter if we happen
to handle web page content events in the UI.

To avoid excessive 'focusTypeChange' events (a single focus or blur
might trigger 'focusTypeChange' twice now: Once in the UI code, and once
in the frame script), this commit also makes sure that setting the
focusType to the same value as before is a no-op.

Fixes #733.

Remove unneeded line of code

VimFx v0.15.0

Update devDependencies

Update nl locale (#731)

Refs. #728.

Update id locale (#730)

Refs. #728

Update de locale (#729)

Refs. #728

Don't trigger VimFx commands in some fancy text inputs

Fixes #725.

Remove unnecessary newline

Add tests for and clean up parse-prefs.coffee

Speed up and refactor Hints mode

This makes most hints show up on screen up to twice as fast as before.
The rest of the hints show up at the same speed as before. Hints
generation has been optimized for the common case, by looking for
markable elements in two passes (if needed and possible). First, we look
for common and fast-to-find elements (such as links); then we look for
everything else. Addresses #409.

Code has been pulled out of marker.coffee, modes.coffee and
hints.coffee, and put into the new marker-container.coffee. hints.coffee
was then renamed to markable-elements.coffee (because all it does now is
finding markable elements).

The concept of tagging elements as "semantic" has been removed. The idea
was to give "unsemantic" elements worse hints (so they wouldn't trump
links, for example). Now, such elements are usually found in the second
pass instead, which gives about the same effect.

`<c-enter>` in Hints mode no longer replaces all hints with new ones for
_all_ elements on screen. Instead, it replaces the hints with hints for
all _unmarked_ elements on screen. Pressing `<c-enter>` again toggles
back to the original hints.

There is a breaking API change for `vimfx.setHintMatcher(hintMatcher)`.
`hintMatcher` no longer receives and returns an object (of the shape
`{type, semantic}`), but instead simply receives and returns the `type`
of the element.

Make it easier to find how to customize hint marker font size

See #727.

Fix a failing test

Pin the coffee-script version

The very latest commits of coffee-script break coffeelint. This pins the
coffee-script dependency to a commit that both compiles VimFx and runs
coffeelint as intended.

Fix frame scripts being loaded more than once sometimes

1. Open several tabs.
2. Set Firefox to remember your tabs between sessions.
3. Restart Firefox. All but the current tab will now be in a "pending"
   (unloaded) state.
4. Update/re-install VimFx.
5. Visit one of the pending tabs.

Now, the frame script will be loaded _twice_ in that tab, which for
example causes `f` to produce double-clicks. This is especially
noticeable during development, when you update/re-install VimFx all the
time.

The reason is that Firefox does not seem to load frame scripts in
pending tabs immediately. Instead, the URI to the frame script we asked
to load is remembered and then loaded when you actually visit the
pending tab in question. If you update VimFx before doing so, yet one
frame script URI will be pushed to that stack, causing _two_ instances
of it to be loaded when visiting the tab. Both of those will be from the
new VimFx version; the URIs are the same, and the file at that URI has
now been updated.

This commit attempts to solve this problem by generating a
`bootstrap-frame-$BUILD_TIME.js` file (which simply runs
`bootstrap.coffee`) and loading that as a frame script. This means that
old saved frame script URIs will point to non-existing files and thus
be harmless.

Fix arithmetic mistakes in `isInsideViewport`

Update zh-CN locale (#726)

VimFx v0.14.3

Fix `scroll.reset_timeout` pref typo

VimFx v0.14.2

Update devDependencies

Don't break the Developer Toolbar when pressing `<escape>`

Fixes #723.

Fix devtools detection in newer Firefox versions

Fix smooth scrolling speed in newer Firefox versions

The following pseudo-code used to work:

    setFirefoxSpringConstant()
    startScrollingSmoothly()
    resetFirefoxSpringConstant()
    // Some time later: Smooth scrolling finishes.

However, in some newer Firefox version that's changed.
`resetFirefoxSpringConstant` now has to be called when the smooth
scrolling is done, it seems. Unfortunately there appears to be no way of
knowing when that's the case. Instead, this commit introduces a timeout
before the spring constant pref is reset. The timeout can be customized
via the `scroll.reset_timeout` pref if needed. Special care was taken so
that, for example, holding `j` to scroll would only reset the pref
_once_ (after the last scroll command) and to the correct value.

Improve copying of element text

Slack uses markdown-style backtick syntax for code spans. Example:

    one `code` two

This is the rendered HTML for the above:

    <span class="message_body">
      one
      <code class="special_formatting">
        <span class="copyonly">`</span>code<span class="copyonly">`</span>
      </code>
      two
    </span>

Previously, `.textContent` was used to copy element text. Because those
backticks actually are there in the DOM, they get copied too. However,
that's unexpected because they're not visible. The `yv` command is
supposed to be equivalent to `zv<hintchars>y`, but this meant that it
wasn't.

This commit instead creates an actual selection and then invokes
Firefox's `cmd_copy` command (which is exactly what `zv` followed by `y`
does). A difference is that now you can see the created selection flash
for a split second, but I actually like that visual feedback.

This fix also has a positive effect on the `yf` command when copying
`contenteditable` elements. Take this markup:

    <div contenteditable="true">T</div>

Then type `<backspace>one<enter><enter>two` in it. Finally, copy the
element using `yf`.

Before, you'd get this:

```
onetwo
```

Now, you get the expected result:

```
one

two
```

Improve Help dialog font spacing

Ignore Lock keys such as NumLock and CapsLock

This makes it possible pressing NumLock and CapsLock in the middle of a
multi-key shortcut without aborting it, allowing to type some keys of shortcut
usinng NumLock and CapsLock.

Note that this remove support for using `<capslock>` and `<numlock>` in
shortcuts, but that was never a good idea anyway, since for example `<capslock>`
would _both_ trigger a VimFx command _and_ toggle CapsLock.

VimFx v0.14.1

Fix Find mode crash

VimFx v0.14.0

Update devDependencies

Tiny documentation fixes

Improve Find mode search start position

By default, Firefox starts searching after the end of the first selection range,
or from the top of the page if there are no selection ranges. This means that if
you search for "vim", a match for "vim" further up or down the page might be
selected, even though the word "vim" might already be onscreen, because of the
current selection (or lack thereof).

Vim starts searching in a similar way: After the cursor. The difference is that
in Vim, the cursor is _always_ onscreen. When you scroll, the cursor is "pushed
along" by the edges of the screen. This way, it is always very easy to tell
where you are going to start your search from. In Firefox, though, using the `/`
command can be quite disorienting.

Another Vim example: Let's say I searched for "vim" again (pressing `/vim` in
Vim). I then go through a few matches using `n`. Then I come to a block of text
that mentions "vim" _lots_ of times, and I realize that I'm not interested in
that block at all. Then it is easier to scroll (or "jump") past that block
rather than spamming `n` over and over (or trying to guess an appropriate
count). When doing the same in Firefox, though, after having scrolled past the
mentioned block of text, the next `n` keypress will scroll up right back to the
last match and continue the search there. This is pretty annoying to me.

While there's the Caret mode (which few people use) and the possibility to
select text in Firefox, there's usually no concept of a caret, and the caret
does not follow the scroll; it stays where it is, possibly offscreen. So where
should we start searching from, really?

This commit implements the following logic:

If there's a visible selection on screen, start searching after that point. If
not, start searching from the top of the current viewport. This works much more
intuitively. Note: Elements with `position: fixed;` are excluded when
determining "the top of the viewport".

Inspired by vimium/issues#1471.

Add missing `require` in commands.coffee

Add missing comments for `utils.bisect`

Improve `zv` caret position

If the start of the element is outside the viewport, put the caret at the first
_visible_ non-whitespace character instead.

Add Caret mode

Fixes #480.

Improve "open link in new tab" interoperability

When opening a link in a new tab, such as when using the `F` or `gf` commands,
we now try to closely mimic what Firefox does when you click links using the
mouse, instead of directly using `gBrowser.loadOneTab(url, options)`.

This provides interoperability with the BackTrack Tab History add-on, which
fixes #720, and allows to remove Tree Style Tab-specific code.

Move viewport calculations from hints.coffee to utils.coffee

It's cleaner and more reusable.

This also fixes a slight bug for markers in frames. Previously, if the frame had
padding and/or borders its calculated viewport was a tiny bit too large. Now,
padding and borders are taken into account.

Change `<c-a>` to `<c-enter>` in Hints mode

Using `<c-a>` for marking _all_ elements was nice, because `<c-a>` usually means
"select all". However, it conflicts with the "hold ctrl when typing the last
hint character to toggle if the link opens in a new tab or not" feature. If the
last character was an "a" that wouldn't happen; instead, the `<c-a>` command
would be invoked. This commit changes to `<c-enter>` which should be conflict
free.

Add the `<c-a>` Hints mode command to mark everything

Fix argument order of an `isInsideViewport` call

Remove horizontal alignment in multiline function calls

This is to reduce unnecessary diffs and to be able to use search-and-replace to
rename things without having to worry about fixing alignment.

Fix `__dirname` in config files on Windows

`OS.Path.dirname` does not seem to support `file://` URIs on Windows.
`OS.Path.dirname('file:///C:/Users/foo/.vimfx/config.js')` returns `'file:'`.

This commit calculates the dirname in a different way to work around the above
problem.

Thanks to @azuwis for finding out and suggesting a fix.

Supersedes and closes #719.

Remove unnecessary full-page hint marker on Hackernews

VimFx v0.13.2

Fix illogical code order in scrolling commands

Logically, one should set the `last_position_mark` mark _before_ jumping
somwhere. However, for the `G`, `g`, `$` and `0` commands, the message to set it
was sent _after_ the message to scroll was sent!

Somehow it has still worked as intended for me.

This commit reverses the order.

This might fix #717.

Allow `<space>` to toggle play/pause in more video players

Fix wrong viewport size for hints in quirks mode

Update devDependencies

Fix lint error

Remove unnecessary `return` in commands.coffee

VimFx v0.13.1

Improve automatic mode switching on page load

Previously, Normal mode was _always_ entered on location change (page load)
(unless the page is blacklisted; then Ignore mode is entered instead). There
were to reasons for this: Handling the blacklist, and auto-exiting hints mode
(because hints left over from another page does not make sense in a new page).
However, this caused a few problems:

- If you used the `zF` command while a page was loading, the markers would
  disappear when the page fired the "location change" event.
- There was an ugly special case for Find mode, making sure not to enter Normal
  mode if currently in Find mode (see commit fc7e61e7c).
- Sometimes, you can enter Hints mode on a newly loaded page just before the
  page fires the "location change" event, making hints annoyingly disappear.

This commit changes two things:

- Hints mode is automatically exited (by returning to Normal mode) on the
  'pagehide' event instead.
- The current mode is only changed on location change _if needed._ That is, to
  auto-exit Ignore mode after navigating away from a blacklisted page, or
  auto-enter Ignore mode on blacklisted pages.

Clear artificial hover on blur

Previously, if you focused an element using an `f` command and then pressed
`<tab>` to focus the next element, or if the element was automatically blurred,
the element would still look hovered until you pressed `<escape>`. This is
because many `f` commands lock the `:hover` pseudo-class on their target
element. This commit unlocks that pseudo-class if that element blurs, preventing
elements from getting "stuck". It is only done if the element itself is blurred,
not if anything else is. That's to make sure that dropdown menus opened using
`zf` don't close unexpectedly.

Fix blacklisting of some XUL pages

Fixes #716.