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.
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.
Improve code readability
Better handling of pseudo-elements
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.
Fix typo in pl locale
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.
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.
Merge pull request #362 from Kambfhase/update-german-locale

updates german locale
Merge branch 'master' into develop
Update install.rdf
Refactor l10n. Fix #363

Helpful links:

- <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIStringBundleService>
- <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIStringBundle>
- <https://github.com/adblockplus/adblockplus/blob/03b965c743f7688622b75b0e7525a17913d7e0ea/chrome/content/ui/i18n.js>
Add missing entity in zh-TW locale
Merge pull request #365 from lydell/refactor-l10n

Refactor l10n. Fix #363
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.
Merge branch 'develop' of github.com:akhodakivskiy/VimFx into develop
Localize to ja(Japanese)
Merge pull request #369 from pluser/localize_ja

Add Japanese localization
Merge pull request #367 from lydell/autofocus-tab-switch-back

Fix #366: Allow autofocus when switching back to a tab
Release v0.5.14