Merge pull request #362 from Kambfhase/update-german-locale

updates german locale

Merge pull request #361 from mozillazg/patch-1

Update zh-CN localization

Update zh-CN localization

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.

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:

    +-------------------------------+
    |1 left-top          right-top 4|
    |                               |
    |2 left-middle    right-middle 5|
    |                               |
    |3 left-bottom    right-bottom 6|
    +-------------------------------+

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.

Fix typo in pl locale

Release v0.5.13

Merge pull request #360 from lydell/last-interaction

Only allow focus events immediately after an interaction

Disallow adding conflicting shorcuts

This has tripped a lot of users up. See #268, #359, #333, #283.

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>

Remove invalid/unnecessary option descriptions

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.

Merge pull request #343 from lydell/better-find-mode

Better find mode

Merge pull request #354 from sirodoht/greek-locale

Update greek translation

Update greek translation
Translate prevent_autofocus strings

Handle a `line-height` special case

Consider the following HTML:

    <p><a href=#>Link text</a></p>

And the following CSS:

    p {
      line-height: 20px;
      font-size: 20px;
      overflow: hidden;
    }
    a {
      font-size: 80px;
    }

Result, with the rectangles of the elements drawn:

    +---------+
    |         |
    |---------+-----------+
    |Link text|           |
    |---------------------+
    |         |
    +---------+

The wide rectangle belongs to the `<p>` while the other belongs to the
`<a>`. The top and bottom part of the `<a>` rectangle, outside of the
`<p>` rectangle (because the `font-size` of `<a>` is larger than the
`line-height`), are hidden due to `overflow: hidden;`.
`document.elementFromPoint()` will only return `<a>` in the area covered
by both rectangles. That is a problem since we start looking at the
top-left corner of the `<a>` rectangle, which will return whatever is
behind.

The solution is to add `line-height: normal;` temporarily to `<a>`,
causing the following (with a comparison to the right):

                               /    +---------+
                               /    |         |
    +---------------------+    /    |---------+-----------+
    |Link text            |    /    |Link text|           |
    |                     |    /    |---------------------+
    |                     |    /    |         |
    |                     |    /    +---------+
    |                     |    /
    +---------------------+    /

This way we can get the correct coordinates, but we only do it as a last
resort, since it is a performance expensive operation.

Better handling of pseudo-elements

Use a `WeakMap` in `utils.Bucket`

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.

Document commit 1b874f1b7b3

Merge pull request #341 from akhodakivskiy/next-prev-matching

next/prev commands

fix recursion in isElementGoogleEditable impl

Better check for Google g_editable in isElementEditable that fixes some issues in Gmail

next/prev commands - search for patterns in element attributes as well. Currenty optimized for Gmail

Fix #334: Make links without `href` markable

Commit be94b559b:

> - 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.

Improve code readability

Build 0.5.12

Version bump and changelog update

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.

Add hints to elements with only floated/absolute children

Commit a3cb61bf:

> - We used to take care of the case where markable elements have no area
>   since all of the children are floated and/or absolutely positioned.
>   For performance I’ve removed that. Let’s re-add it if we find some
>   website that needs it. The old implementation used the computed style
>   for this, which has turned out to be really slow.

Since then I _have_ found such cases. A link in a menu could contain a
span of text floated to the left and an icon floated to the right.

So I’ve re-added support. Best of all, with better performance than the
old implementation; computed style is _not_ used.

It turns out that if the width _and_ the height of an element is 0 (thus
making the area 0, too) it is really hidden. But if only one of the
width and height is 0 (also making the area 0), then it is because
everything inside it is floated and/or absolutely positioned (and that
`element` hasn’t been made to “contain” the floats). Then there’s no
need to check any computed style. Just recursively test each child until
a visible one is found and return its shape instead of the parent.

The reasoning behind choosing the first visible child is as follows:

- It’s the best bet for the cases with menu items I found. We want the
  marker at the beginning of the menu item. The text spans, floated to
  the left, are likely the first children.

- We _could_ add the same hint to _all_ the visible children. But that’s
  a bad idea for a couple of reasons:

  - It would be inconsistent with all other elements. Even elements with
    an area can contain floated elements, which are also clickable. But
    those do not get any hints. (It would be too expensive
    performance-wise to give them hints, for no real benefit.) Therefore
    we shouldn’t do it in this case either.
  - In the found cases with menu items we only want _one_ hint, for the
    whole menu item. We should optimize for the likely cases.
  - It would be unnecessarily complex and slow.

Build version 0.5.11

Version bump and changelog update

Merge pull request #322 from lydell/fix-autofocus

Fix autofocus

Improve marker generation. Fix #325.

- Elements covered by other elements do no longer get hints. This makes
  it easier to use drop-down menus when there are lots of links behind
  it.

- Elements partly outside the screen now get hints, too.

- Partly covered elements get hints, too. The hint is placed in the
  first non-covered point of the element.

- Line-wrapped links now get their hint in a better place. This is
  easiest to explain with a picture. # = old hint location, * = new hint
  location (approximately)

  #---------+
  |   *Line-|
  |wrapped  |
  +---------+

  Such links also used to count the whole of that box as its area. Now
  only the actual text is counted, giving the marker a more fair weight.

- We used to take care of the case where markable elements have no area
  since all of the children are floated and/or absolutely positioned.
  For performance I’ve removed that. Let’s re-add it if we find some
  website that needs it. The old implementation used the computed style
  for this, which has turned out to be really slow.

- We used to check if elements were hidden with CSS (if `opacity: 0;` or
  `visibility: hidden;`), but we don’t anymore, since it noticeably
  slows down the marker creation (checking computed styles is slow). It
  does not appear to be necessary anymore. It was added to fix #164, but
  the problems there now seem fixed even without this check.

- The code should be more documented now than before.

- The performance is better than before. It does not seem like the new
  algorithms are slower. And since I’ve removed two slow areas, it might
  be a little faster.

Remove stray `console.log`s

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.

Cleanup CSS a bit

Remove old VimFxFindInput CSS

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.

Improve contenteditable detection

Bump minimum Firefox version (see #314)

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.

  Reference:
  <http://developers.whatwg.org/text-level-semantics.html#the-a-element>

- Elements with the `tabindex` attribute should be matched, but not
  `tabindex=-1`, which means explicitly saying that the element should
  _not_ be focusable.

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.

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>

This commit is based on #313 by @zhuochun.

Expose xpath utils

Previously xpath usage was closely tied to the `getMarkableElements`
function.

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!

Fix #310: Broken focus search bar command

Add missing parenthesis

Merge pull request #312 from zhuochun/bug-263-can-add-blank-hotkey

Fix #263 can add blank hotkey

clean up code around conflict_cmd

ignore empty cmd value

0.5.10 vesion bump and changelog update

Fix bug when loading default preferences

Update 0.5.9 changelog to mention gg/G speedup fix

Added all historic builds

Merge branch 'develop'

Merge branch 'develop' of github.com:akhodakivskiy/VimFx into develop

Merge branch 'release-0.5.9'

version bump and changelog update

Fixed default properties

Put commands in the same order as the `commands` array

Update `command_insert_mode`

Update move tab commands

Update `command_restore_tab`

Update `command_back` and `command_forward`

Update `command_tab_first` and `command_tab_last`

Update `command_home`

Update `command_tab_prev` and `command_tab_next`

Fix #189: Speed up scoll to top/bottom commands

Update stop commands

Update reload commands

Update `command_marker_yank` and `command_yank`

Conflicts:

extension/packages/utils.coffee

Update `command_open_tab`

Update `command_paste` and `command_paste_tab`

Update `command_focus_search`

Update `command_focus`

Update `command_dev`

Add `Vim::rootWindow` for convenience

Remove the `storage` parameter for commands

None used it.

0.5.8 version bump

Merge pull request #290 from cbertoldi/master

Added italian translation.

Added localization.

Added italian translation.

Merge branch 'release-0.5.7'

hotfix release. version bump and changelog update

Merge branch 'master' into develop

Bug fixes

Merge pull request #287 from mozillazg/zh-CN

Update zh-CN localization

Update zh-CN localization

Merge branch 'develop'

Merge branch 'release-0.5.6' into develop

Merge branch 'release-0.5.6'

Version bump, changelog update, bump max version to 29

Fixed mistake in next/prev patterns

Merge branch 'develop' of github.com:akhodakivskiy/VimFx into develop

Merge pull request #273 from akhodakivskiy/prevent-autofocus

Prevent autofocus

Prevent autofocus by blurring the input if it's been focused in the first second after loading is finished

Workaround for command shortcuts that start with letter c

Merge pull request #285 from sirodoht/develop

Update Greek localization

Update Greek localization