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 [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.
Simon Lydell [Fri, 4 Dec 2015 19:37:10 +0000 (20:37 +0100)]
Improve `gi` text selection
Before you have focused a text input (a prevented autofocus does _not_ count),
`gi` now selects all text in the text input it focuses (before, it only did so
for inputs that had autofocus prevented). The reason is that many sites prefill
search boxes with your query on search results pages. Then it’s nice if `gi`
selects all the text, letting you quickly replace it.
Simon Lydell [Fri, 4 Dec 2015 07:12:02 +0000 (08:12 +0100)]
Fix scrolling of `<html>` if `<body>` is scrollable
`document.activeElement` is never `null`. If no element if focused, it is
`document.body`. If `document.body` is scrollable, it means that `<html>` can
never be scrolled.
This commit only allows to scroll `<body>` if it has been explicitly focused (or
if it is the largest scrollable element, of course).
Simon Lydell [Thu, 3 Dec 2015 07:20:43 +0000 (08:20 +0100)]
Fix text selection when forusing text inputs
When using one of the `f` commands to focus a text input, the previous selection
or caret position should be retained, just as if you had clicked it. However,
before this commit all of their text was accidentally selected (as if you had
pressed `<tab>` to foucs).
This also improves the `gi` command. Previously, it _always_ selected all text.
Now it does so only if you use a count, or use `gi` to re-focus an input after a
prevented autofocus. In those cases you likely want to replace what's in the
input, but otherwise you're likely returning to the text input after a temporary
leave and want to continue typing where you left off.
Simon Lydell [Wed, 2 Dec 2015 06:37:53 +0000 (07:37 +0100)]
Fix some links not being targeted by `F`, `gf` and `gF`
In commit af0c4a07, links with an 'onclick' attribute stopped being considered
as "proper". The reason was to prevent such links from getting the same hint as
other links with the same href, because the 'onclick' likely makes all those
links behave differently.
However, on startpage.com the search result links actually are "proper" links,
but also have 'onclick' attributes and since that caused them not to be
considered as proper, they did not get hints when using `F`, `gf` and `gF`
commands.
This commit considers links with 'onclick' as proper again, and only excludes
them from getting the same hint as other links.
Simon Lydell [Mon, 30 Nov 2015 13:57:34 +0000 (14:57 +0100)]
Add window commands
- `w`: Open new window.
- `W`: Open new private window.
- `gw`: Move tab to new window.
- `gF`: Follow link in new window.
Fixes #402.
In #402 two more commands were discussed:
- `q`: Close window. Can easily make more harm than good. Also, why learn a
Firefox-specific shortcut to close a window, when you can use an OS-wide
shortcut?
- `Q`: Suggested only for symmetry with `x` and `X`. YAGNI.
Simon Lydell [Thu, 26 Nov 2015 09:51:41 +0000 (10:51 +0100)]
Rework "move tab to window" detection logic
The old detection was too unreliable and didn't catch all cases.
Also fixes a bug where the blacklist wasn't applied when going back or forward
in history to a blacklisted URL.
The long story:
If you move a tab into another window in multi-process, the frame script for the
web page of the tab is kept. That is good, since all state (such as scrollable
elements) is preserved.
In non-multi-process, that is not the case. A new frame script is loaded, so all
state is lost. That is unfortunate, but there's nothing we can do about it. In
non-multi-process, moving a tab to another window then works a bit like closing
the tab and opening a new one in the target winow with the same URL: All VimFx
state is lost, including the current mode. The blacklist is applied. However,
the web page content is the same, with DOM modifications and scroll position
preserved. This is not ideal for VimFx, but OK. Non-multi-process will be
dropped from Firefox not too far into the future anyway.
Let's focus on multi-process instead.
That no new frame script is loaded for the "new" (dragged) tab in the target
window has some interesting consequences. For example, `vim` objects for tabs
are created based on a frame script being loaded. Does this mean that no `vim`
object is created for this tab? It depends.
When a new tab is opened, Firefox might load a frame script for `about:blank`.
When the real web page starts loading, a new frame script is loaded.
The above can depend on whether you're moving (dragging) a tab to another
existing window, or moving a tab to an entirely new window (by right-clicking a
tab and choosing “Move to New Window” or dragging a tab and dropping it outside
a tab bar).
If a frame script for `about:blank` _is_ loaded, a `vim` object is created.
However, Firefox then moves over the web page from the old tab, and replaces the
`.messageManager` of the new tab’s `<browser>`! This means that the `vim` object
cannot receive messages from the just-moved-over web page (coming from the frame
script that was kept from the origin window, as mentioned earlier), because it
has attached its listeners to a message manager object that no longer exists.
In both cases it means that VimFx won't work correctly in those tabs. Therefore,
we need to detect tabs moved to other windows.
There does not seem to be any straight-forward way of detecting that, though.
However, we can abuse the fact the `vim` objects for those tabs will either be
missing or have the wrong `._messageManager` as a way of detecting it anyway.
(Since that isn't the case in non-multi-process, that's why we can't detect it
there.)
After having moved a tab to another window, the web page of the tab loads from
cache. This triggers a 'pageshow' event with `event.persisted === true`, just
like when navigating forward and backward in history. When this happens, the
frame scripts send a message to the UI process, which is caught at window level.
If there's no `vim` object for the `<browser>` that the message came from, or if
`vim._messageManager` is out of date, we know that the tab for the `<browser>`
element has just been moved to another window!
In that case, we want to find the `vim` object for the closed tab in the origin
window (the one that we started dragging, for example) and re-use it for the
"new" tab, in order to keep the current mode etc.
That is done be saving the `vim` object of the last closed tab, by listening for
the 'TabClose' event. It fires before the new tab in the target window is
created.
The whole process is very ugly and a bit complicated, but there's seems to be no
other way, and it does the job: Things work acceptably in non-multi-process and
(seemingly) perfectly in multi-process.
Simon Lydell [Tue, 24 Nov 2015 17:37:40 +0000 (18:37 +0100)]
Implement simple marks
Inspired by Vim and Vimium, but simpler. All they do is to save the current
toplevel scroll position for the current page, letting you return to that point
later. Global marks are intentionally left out: See #626.
Simon Lydell [Sun, 22 Nov 2015 16:28:51 +0000 (17:28 +0100)]
Fix broken updating of the button
When moving from `@vimfx.emit.bind(@vimfx, 'TabSelect', event)` some time, that
code was mistakenly changed to `@vimfx.emit(@vimfx, 'TabSelect', event)` instead
of `@vimfx.emit('TabSelect', event)`
Simon Lydell [Sun, 22 Nov 2015 11:26:14 +0000 (12:26 +0100)]
Fix hints mode not exiting when focusing text input
`marker.type` (which is `undefined`) was used instead of `marker.wrapper.type`
when checking if it is `'text'`. This caused for example `af` not to exit hints
mode when typing the hint for a text input.
Simon Lydell [Sun, 22 Nov 2015 10:03:59 +0000 (11:03 +0100)]
Improve largest scrollable element detection
In commit f405054c a special case was added for the root element:
> Consider the entire page as largest if scrollable
>
> Its area may technically be less than other elements, but if it is scrollable
> that's what you expect to scroll.
However, if you embed such a page in a frame, the page won’t be scrollable
(because it is not the uppermost root element).
This made me realize that it makes the most sense to consider the _uppermost
scrollable element_ the largest. In other words, if a scrollable element
contains another scrollable element (or a frame containing one), the parent
should be considered largest even if the child has greater area.
Simon Lydell [Sun, 22 Nov 2015 08:57:31 +0000 (09:57 +0100)]
Fix being unable to scroll in quirks mode
Alternatively:
Handle quirks mode in a better and more abstracted way.
In quirks mode, `<html>` might receive an 'overflow' event, but it is `<body>`
that is scrollable (and it does _not_ receive an 'overflow' event!) The
`ScrollableElements` class now automatically takes care of this case, storing
`<body>` instead if you try to store `<html>` in quirks mode. This way, only
actually scrollable elements are stored, which makes comparisons such as
`isScrollable` work without having to think about quirks mode. Previously, the
`isScrollable` check in the 'overflow' event handler failed on `<html>` in
quirks mode, making it impossible to scroll on quirky sites, such as Hackernews.
Simon Lydell [Sat, 21 Nov 2015 12:57:04 +0000 (13:57 +0100)]
Fix text input focus problems since commit a197a16
Since that commit, and only in non-multi-process, when focusing a text input for
a second time it got styled as focused, but no blinking text caret appeared. You
could still type into the text input, though.
Simon Lydell [Sat, 21 Nov 2015 10:22:26 +0000 (11:22 +0100)]
Improve scrollable element detection when zoomed
Elements may overflow when zooming in or out. However, the `.scrollHeight` of
the element is not correctly updated when the 'overflow' event occurs, making it
possible for unscrollable elements to slip in. An example is Google Groups.
There, the entire page gets an 'overflow' event when zooming, and by then it
actually looks to be scrollable. When inspecting the element afterwards, though,
it becomes clear that it is not. Well, actually, then it looks like the element
is scrollable by 1px. So this commit also sets a minimum scroll to 5px.
The solution to the zoom problem is to check if the largest scrollable element
really is scrollable before trying to scroll it. If not, update it.
Simon Lydell [Wed, 18 Nov 2015 18:11:02 +0000 (19:11 +0100)]
Simplify scrollable element rejection
One 'pagehide' event is fired for every removed frame, starting with the most
deeply nested one, so there's no need to do a deep containment check for
scrollable elements.
Simon Lydell [Wed, 18 Nov 2015 13:54:20 +0000 (14:54 +0100)]
Enhance `overflow` check for scrollable elements
Checking the computed style for `overflow` proved to be a bit reliable.
Explicitly checking both `overflow-x` and `overflow-y` works better. If both are
set to `hidden` the element is not scrollable.
Simon Lydell [Tue, 17 Nov 2015 08:36:53 +0000 (09:36 +0100)]
Fix state being lost on some pages
... especially the largest scrollable element, usually `<html>`.
Since commit 87ece2ac we use the 'readystatechange' to detect location change in
a tab. While that seems to work fine, resetting state at that point does not.
Apparently, at least on some sites, a 'readystatechange' with `readyState ==
'interative'` is fired _after_ `<html>` has been detected as a scrollable
element, causing that scrollable element to be lost (because of a state reset).
If another scrollable element is detected after that, scrolling the entire page
becomes impossible.
Luckily, the 'pagehide' event seems to be exactly what we're looking for, when
it comes to resetting state. It also has the bonus of firing in frames, removing
the need for the `MutationObserver`s for frames added in commit ef5e2366.
Simon Lydell [Mon, 16 Nov 2015 20:54:21 +0000 (21:54 +0100)]
Fix broken notifications
I got it wrong in commit 340584c8 and believed that only one `<statuspanel>` was
needed per window, but one is actually needed for every _tab._ Luckily, the code
became a lot simpler.
Simon Lydell [Wed, 11 Nov 2015 17:03:40 +0000 (18:03 +0100)]
Rework how notifications are shown
Users found `new Notification(message)` too intrusive. This commit shows
notifications in a `<statuspanel>` instead, like the "URL popup" (shown when
hovering or focusing links), but on the opposite side.
When pressing `n` or `N` and the search matches a link, the URL popup is shown.
Putting the VimFx notification on the opposite side allows both to be visible at
the same time.
Notifications are shown until you click them, press a key or switch tab.
Simon Lydell [Thu, 12 Nov 2015 18:55:08 +0000 (19:55 +0100)]
Properly exit "`gi` mode"
Before, if you pressed `gi`, blurred the text input and then focused a text
input (without using Hints mode, such as using `<tab>` or clicking), you would
still be in "`gi` mode", making `<tab>` only cycle between text inputs.
Simon Lydell [Thu, 12 Nov 2015 08:31:08 +0000 (09:31 +0100)]
Rework `gi` handling of `<tab>`
The "Focus previous/next element" commands turned out to be too intrusive. This
commit removes them, and instead handles `<tab>` and `<s-tab>` especially. Those
keys are handled:
- _only_ in web page content.
- _only_ if in "`gi` mode".
- always "late", taking `event.defaultPrevented` into account.
- not if `<tab>` or `<s-tab>` was part of a command shortcut.
This commit removes some (theoretical) flexibility in order to stay true to our
goal not to interfere with the browser.
git://git.gir.st / VimFx.git / log