Simon Lydell [Tue, 12 Jan 2016 08:13:55 +0000 (09:13 +0100)]
Fix misplaced hint markers when zoomed
Hint markers are supposed to be centered vertically on the non-covered point.
This didn't work properly when zoomed, but now does. For simplicity, that fix
removed the "make sure the marker stays within its element" constraint, which
turned out to be nice and more consistent. The hint markers are now _always_
centered vertically on the non-covered point, even for very small links.
This commit also fixes hint marker placement in the devtools when the devtools
have been independently zoomed. The above issue needed to be fixed before this
could be fixed. Fixes #667.
Simon Lydell [Mon, 11 Jan 2016 18:32:02 +0000 (19:32 +0100)]
Fix memory leak in non-multi-process Firefox
Apparently, 'overflow' and 'underflow' events in web page content can be caught
in UI listeners in non-multi-process. `event.target` of 'overflow' events in the
browser UI are saved as scrollable elements, which accidentaly included web page
elements as well. Holding on to such elements after their owner tab is closed
caused a memory leak (ghost windows). This commit checks that the overflown
elements really are UI elements before saving them.
Simon Lydell [Sat, 9 Jan 2016 16:39:07 +0000 (17:39 +0100)]
Fix `:hover` clearing on click in multi-process
Because clicks simulated by VimFx apparently cannot be caught in non-frame
listeners (which is good), _two_ real clicks were needed to clear `:hover`. This
commit fixes that, which allowed for a nice code cleanup. Instead, a temporary
hack is used for non-multi-process to make it work there.
Simon Lydell [Wed, 6 Jan 2016 13:22:25 +0000 (14:22 +0100)]
Lock `:hover` when clicking with the `f` commands
Fixes #388.
Note that this commit also adds `pointer-evets: none;` to the hints container,
allowing to generate hints for elements only visible because of the mouse
pointer hovering something. Getting hints for hover-menus opened by `zf` but not
for hover-menus opened by moving the mouse was too confusing. The reason
`pointer-events: none;` wasn’t added before was that it prevented from scrolling
while hints were shown. While that was nice, it was just an edge case that
doesn't really matter. It is better to allow hints for hover-menus.
Simon Lydell [Wed, 6 Jan 2016 09:40:50 +0000 (10:40 +0100)]
Improve element matching for the `zF` command
- Always exclude `<menuitem>`s. They are never clickable by VimFx. (This could
be seen in the Responsive Design View).
- Oddly, `<menuseparator>`s are considered focusable, but of course shouldn't
get hints. Now they don't anymore.
- Make sure that browser elements in the web page content area (such as in the
Responsive Design View) only show up when their containing tab is selected.
Simon Lydell [Wed, 30 Dec 2015 15:43:26 +0000 (16:43 +0100)]
Make 'frameCanReceiveEvents' more robust
Instead of using a combination of `.readyState in ['interactive', 'complete']`
and the 'DOMWindowCreated' event, only set 'frameCanReceiveEvents' to `true`
when `.readyState == 'complete'`. Also, set it to `false` on the 'pagehide'
event. This simplifies things a bit, and hopefully makes VimFx more responsive
on slowly-loading pages. See #588.
Simon Lydell [Mon, 21 Dec 2015 07:16:00 +0000 (08:16 +0100)]
Treat contenteditable elements as other text inputs
This lets `gi` focus contenteditable elements, which are often indistinguishable
from `<input>`s and `<textarea>`. It also allowed for some nice code cleanup.
Simon Lydell [Sun, 13 Dec 2015 10:03:19 +0000 (11:03 +0100)]
Improve the help dialog UX
- The search field is no longer autofocused. This is to allow the following
points. It also allows to try out commands while the dialog is open; see #619.
- The scrolling commands now scroll the help dialog if it is open (regardless of
whether it is scrollable or not, instead of confusingly scrolling the page
behind it).
- The search field is focused by pressing `/` (or `a/` or `g/`).
- The search field is hidden until focused, reducing the risk of it obscuring
text.
Simon Lydell [Wed, 9 Dec 2015 16:45:05 +0000 (17:45 +0100)]
Reset typed keys in "autoInsertMode"
Previously, if you typed for example a 'g' in a text input, click
outside it to unfocus, and then tried to use the `/` command, `g/` would be
triggered instead.
Simon Lydell [Tue, 8 Dec 2015 18:36:31 +0000 (19:36 +0100)]
Make it possible to scroll browser elements
The dev tools can contain scrollbars. This commit makes it possible to focus
such scrollable elements with `zF` and then scroll them using all of VimFx's
scrolling commands.
Simon Lydell [Sun, 6 Dec 2015 16:50:32 +0000 (17:50 +0100)]
Add command to click browser elements using markers
Fixes #236.
A note about the "hamburger menu" in the top-right corner:
It is possible to _open_ it with `zF`, but not possible to use `zF` inside of
it, because of `@popupPassthrough`. One _could_ an exception for that
menu/popup, but that doesn't help:
- `.elementFromPoint()` does not appear to find elements in popups, making it
difficult to determine if the buttons inside are visible or not.
- The markers appear _behind_ the popup, no matter what `z-index` is used.
- The popup seems to eat `<escape>`: When it is pressed, the popup is closed,
but the markers remain. The next `<escape>` press removes the markers. Not a
big deal, but slightly annoying.
Therefore I decided not to add support for that menu in this commit. (Perhaps
we'll be able to do that some time in the future.) Instead, I recommend using
the alt key shortcuts for the "regular" menubar.
Simon Lydell [Tue, 8 Dec 2015 19:43:51 +0000 (20:43 +0100)]
Remove try-catch in UI 'keydown' listener
Firefox unfortunately doesn't show the stack trace in its error consoles. Still,
there is one available on thrown `error` objects. That's why the try-catch used
to be there: To also show the stack trace. Wrapping the 'keydown' listener was a
good choice because most things happen on keydown in VimFx. However, since the
switch to multi-process Firefox, this is less useful. Most keys are captured in
frame script 'keydown' handlers, not in the UI, so the try-catch didn't do much.
One _could_ place the try-catch somewhere else instead, but now it's harder to
find a good place. Besides, I've not really missed the stack trace for the last
couple of months. The file name and line number is still reported which is good
enough.
Simon Lydell [Sun, 6 Dec 2015 14:53:18 +0000 (15:53 +0100)]
Add notifications to many commands
If nothing happens when activating a command, a notification is shown instead,
making it obvious that you actually triggered the command and didn't press the
wrong keys.