| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
The stripped code is all relocated in #1413.
|
|
If focusInput does not find a visible input, then pop up the HUD to tell
the user. Without this, the user gets no feedback as to what happened.
|
|
|
|
This was an oversight from #1413 (that find mode exits in this
circumstance).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
focusInput was getting its focus events from the handler stack. When
the handler stack was reset during tests, we lost focusInput's handler.
So we couldn't test the feature whereby focusInput has a memory (#1438).
Instead, here focusInput adds its listener directly to the window, and
we add the approriate test.
|
|
|
|
- Set up modes such that they can be re-initialised.
- Move initialisation of BadgeMode to general initialisation function.
- Add reset() method for handlerStack.
- Consistently use initializeModeState() in all tests' setup().
- Refactor focusInput tests.
- Add some more tests.
- Simplify some other tests.
Note: Clean-up of the inputFocus overlay now happens when the exit()
method is called in Mode.reset(). This eliminates most needs to
artificially bubble a keyboard event to clear the overlay.
|
|
Give focusInput (gi) a memory
|
|
Caught this while working on the dom_tests infrastructure. Testing
works!
|
|
This makes the diff look big, but that's mainly due to a change in
the indentation.
|
|
|
|
|
|
I had intended the whole Insert.permanentInstance lark to be gone before
merging #1413. Somehow, this got missed.
It's retained, here, but is only needed for the tests. It gives the
tests a hook into the single insert-mode permanent instance, so they can
test its state.
|
|
|
|
|
|
We were blurring the active input element whenever we exit insert mode
(my bad). It should only be blurred when we exit insert mode via
Escape.
|
|
|
|
- Track the most recently-focused input.
- When focusInput is launched (with a count of 1) start with the most
recently focused input.
This does two things:
- If the user is editing an element then comes back, they end up back
where they started.
- It gives focusInput a memory.
|
|
Fix slightly wonky perform-find-in-place
|
|
A modal-browsing framework
|
|
|
|
|
|
|
|
Mainly reduce code duplication.
|
|
|
|
This fixes #1096.
|
|
|
|
- Mainly comments.
- Rename chooseBadge to updateBadge (for consistency).
- No badge for passkeys; also fix tests.
|
|
|
|
|
|
|
|
|
|
- refactor PostFindMode (to keep separate functionality separated).
|
|
|
|
|
|
|
|
|
