| Age | Commit message (Collapse) | Author |
|---|
|
use Element::scrollBy if it exists
|
|
This reverts commit aff380669445594e7566a835d4b27f11da26ea6a.
This breaks scrolling on Twitter.
Needs more thought.
|
|
This selects the body of a message, if such is displayed.
|
|
1. Use verb phrase for function name.
2. Add `Scroller.reset()` method. This *only* resets the activated element.
3. Reset the scroller only if the URL has changed. (Previously, in #3119, the scroller was also being reset when the tab gained the focus.)
Based on a suggestion from @marcotc.
|
|
|
|
|
|
|
|
|
|
Twitter is an important site and Vimium's scrolling is currently broken
when a tweet is expanded.
In my opinion, the existing bahviour is so bad and that a site-specific
hack is warranted.
Fixes #3045.
|
|
|
|
|
|
This is a workaround for Firefox bug 1408996.
|
|
|
|
Steps to reproduce:
- Press and hold `j`.
- Tab `k`.
- Release `j`.
The tap on `k` is uninstalling the `cancelEventListener` installed by
`j`, and because we advance `@time`, the `j` stops scrolling and
removes the `cancelEventListener` installed for `k`. So we end up with
no `cancelEventListener` installed.
The fix is to make the `cancelEventListener` specific to the scroller
instance.
The more fundamental problem here is that we're mixing dynamic and
static state. A better approach would be to have `CoreScroller` as a
class, with a new instance created for each scroll instance.
|
|
Here's the problem...
Many sites define their own keyboard shortcuts, for example Google Play
Music defines `gh` for "go home".
On such sites, it's natural to set up pass keys for `g` and `h`.
But that makes any Vimium key bindings which begin with `g`
inaccessible.
Here, we add a new command `enterNormalMode` which installs a new
normal-mode instance (without any pass keys). This executes a single
normal-mode command then exits.
Example:
map \ enterNormalMode
map | enterNormalMode count=999999
Assuming `g` and `o` are pass keys:
- `gh` or `o` - use the page's binding
- `\gg` - scroll to top
- `2\ggo` - scroll to the top and open the Vomnibar
- `\g<Escape>o` - open the Vomnibar
- `\<Escape>o` - use the page's bindings
- `\\\\\\<Escape>o` - use the page's bindings (new normal-mode instances
displace previous ones)
This required some changes to the scroller. Previously, we only ever
had one normal-mode instance, and could arrange statically that the
scroller's key listeners were above normal-mode's key listeners in the
handler stack. Here, we fix this by adding and removing the scroller's
listeners dynamically, so they're always at the top of the handler
stack.
|
|
Instead of setting a property of document for `scrollingElement` (if it
is not defined), just use a function and make the decision dynamically
instead.
|
|
This fixes Vimium with the 'Experimental Web Platform Features' flag
enabled, and ensures compatibility across quirks mode scrolling (via
document.body) and standards-compliant scrolling (via
document.documentElement).
|
|
Fixes #2092.
|
|
Scrollable divs are offered via link hints. It makes no sense to offer
the current activated element for selection - so don't.
On a "normal" page where there's just one scrollable thing,
document.body, this means that we no longer offer the unnecessary
"Scroll." hint.
|
|
Fixes #425.
Conflicts:
content_scripts/scroller.coffee
|
|
- Refactor the three visual-mode modes.
- Use the key-handling framework from #2022.
- Strip some legacy edit-mode code.
- Rename the file (the old file name was misleading).
- Add "aw" and "as", previously we had the code for this from edit mode.
|
|
When the scrollers `activatedElement` isn't scrollable, we currently
search up the DOM tree for the next scrollable thing, and stop at
`document.body`. However, it can be that that isn't scrollable.
When that happens, this commit searches for a scrollable element in the
same way as it does when the frame initially loads. This makes it
possible to restart scrolling on pages like this one:
- http://redux.js.org/docs/basics/UsageWithReact.html
after clicking one of index links.
Inspired by example posted by @marlun in #425.
|
|
|
|
If we miss the keyup event while a smooth scroll is active (because the
focus changes), then we scroll forever. This stops scrolling on blur.
Fixes #1788.
|
|
|
|
|
|
Fix bounds and amounts in Scroller.scrollIntoView
|
|
|
|
|
|
This fixes #1596.
|
|
|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
lib/keyboard_utils.coffee
|
|
I'm seeing a strange scrolling bug on some pages, for example, here:
http://www.steephill.tv/tour-of-qatar/.
Background:
When we scroll, we first have to decide which element to scroll.
Because of a chrome bug, we do this by testing candidate elements:
scroll the element up by one px, then back down again. If it moved,
then it's scrollable, and it's the element we should scroll.
Bug:
In some cases, the micro-scroll-up succeeds, but the subsequent
micro-scroll-down fails. It's not clear how this could happen. It
may be a chrome bug. In any case, as a result, we conclude that the
element is not scrollable, and proceed to the next candidate. We end
up finding no scrollable element, and j/k scrolling is broken. If
you press-and-hold "j" or "k", you can see the repeated
micro-scroll-ups.
Problem:
I can't reproduce this in a clean chrome account. I only see it in
my live chrome instance. I've tried disabling all extensions, but
the problem persists. So there's something else at play, but I
haven't yet been able to track it down.
Solution:
This commit is a temporary workaround. We just default to scrolling
document.body if we can't find anything else to scroll. Most of the
time, that's the right thing to do. And it's what we would have done
prior to implementing smooth scrolling. Nevertheless, it isn't a
great solution...
Notes:
It's possible that this is related to #1117. However, users there
have reported *not* seeing the micro-scrolls. So probably not.
I'm not posting this as a PR, because I can't reliably reproduce the
bug. However, the fix pretty much does what we did before smooth
scrolling, it's almost certainly safe. So I'm just pushing this
straight into master.
|
|
- convert getCaretCoordinates from JS to CS
- handle x axis in scrollIntoView
- better comments throughout.
|
|
|
|
This reverts commit 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8.
Nope. This is bad. It fixes the issue referred to in the commit
record, but breaks scrolling out of text areas.
With 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8:
- Start editing in a text area, add enough text that it scrolls.
- `Escape`
- `k`, `k`, `k`, ...
We expect first the text areas to scroll, then -- when it reaches the
top -- the document to scroll. However, with
90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8, we get stuck in the text
area.
|
|
This reverts commit 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8.
Nope. This is bad. It fixes the issue referred to in the commit
record, but breaks scrolling out of text areas.
With 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8:
- Start editing in a text area, add enough text that it scrolls.
- `Escape`
- `k`, `k`, `k`, ...
We expect first the text areas to scroll, then -- when it reaches the
top -- the document to scroll. However, with
90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8, we get stuck in the text
area.
|
|
On this page:
- http://www.steephill.tv/dubai-tour/
I was seeing a scrolling problem in my live browser (j/k didn't work
until I clicked on the page), but couldn't reproduce it directly in my
test browser. That's worrying.
Nevertheless, what was happening was that we succeeded in scrolling a
test amount in one direction, but the scroll to revert failed. The
consequence was that we concluded (incorrectly) that the element doesn't
scroll. And j/k scrolling is broken as a result.
How can it be that a scroll in one direction succeeds, but the reverse
does not?
This fixes the problem by not checking whether we are able to undo the
scroll of our test amount.
|
|
On this page:
- http://www.steephill.tv/dubai-tour/
I was seeing a scrolling problem in my live browser (j/k didn't work
until I clicked on the page), but couldn't reproduce it directly in my
test browser. That's worrying.
Nevertheless, what was happening was that we succeeded in scrolling a
test amount in one direction, but the scroll to revert failed. The
consequence was that we concluded (incorrectly) that the element doesn't
scroll. And j/k scrolling is broken as a result.
How can it be that a scroll in one direction succeeds, but the reverse
does not?
This fixes the problem by not checking whether we are able to undo the
scroll of our test amount.
|
|
|
|
|
|
- implement "i", "a".
- fix "w" for edit mode.
- try out "e" for enter edit mode.
- initial implementation "o", "O"
- Suppress backspace and delete.
- Scroll in text areas.
|
|
- Better abstraction.
- Add HUD message on yank.
- Require initial selection for visual mode.
- Try to start with a visible selection.
- Scroll the active end of the selection into view (with smooth
scrolling, if enabled).
|
|
|
|
- Set Mode.debug to true to see mode activation/deactivation on the
console.
- Use Mode.log() to see a list of currently-active modes.
- Use handlerStack.debugOn() to enable debugging of the handler stack.
|
|
|
|
The right scrollable element to choose may be scrolled to the bottom, so
we won't find it if we only test scrolling down. We need to test
scrolling up as well.
|
|
We could incorrectly initialize activeElement to document.body if the
scroller is called too early; so delay initialization. It's safe to
leave activeElement as null.
|
|
|
|
See #1358.
|
