| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes #2958 (probably).
This appears to be correct for target "_blank" (or not) and modifiers
(or not). That's four cases.
It will be *incorrect* if there is a click listener on a target "_blank"
link. Some conditions are tested to try to prevent that from happening.
This only affects Firefox. Chrome is unaffected.
|
|
Fixes #2860. That issue reports that, when the target is "_blank",
Firefox/Vimium ends up opening two tabs.
|
|
This restores the old behaviour prior to
c4cc76e9f6a0a99ebc297e420be739a0fc77f827 (PR #2772).
|
|
|
|
Credit to @gdh1995 for catching these oversights.
|
|
|
|
This is a workaround for Firefox bug 1408996.
|
|
Inject user css into all frames
|
|
|
|
|
|
|
|
|
|
|
|
Mention @mrmr1993.
Mention @gdh1995.
We have zoom issues resulting from:
- style
- zoom
- --force-device-scale-factor=1.5
- HiDPI
This intended to fix HiDPI, but seems to have created problems in the
some of the other cases.
I don't have time to figure out the problem right now, so I'm going to
revert this and push it as 1.60.2.
That leaves us pretty much where we were before, I think, in terms of
zoom.
We can come back to it later.
|
|
|
|
This should fix #2635, fix #2633 and fix #2620.
|
|
|
|
@mrmr1993... This puts the logic of how we choose the selection type in
one place; so, if you have a better idea of how to determine the
selection type, then we just change it here. Once.
|
|
This is a no-op. It is preparatory to implementing a suitable polyfill
for `selection.type` for Firefox.
|
|
|
|
|
|
That is, allow at most one handler to be installed at any one time.
I have not observed this to be necessary. However, if there were any
systematic way in which we weren't seeing the necessary keyup events,
then these handlers would just be added and added. So this seems safer.
|
|
This avoids the possibility of leaking keyup events if the keys a
released in a different order from that in which they were pressed.
Also, replace suppressKeyupAfterEscape with this same mechanism.
This fixes a bug (in master/1.59) whereby we leak the keyup event for
`i` when entering insert mode.
TODO:
- `/`, `<Escape>` leaks a keyup event
- `i` leaks a keyup event
|
|
Keyboard repeats were interfering with smooth scrolling. But we should
be ignoreing them anyway.
|
|
|
|
getViewportTopLeft: support zoomed static documentElement
|
|
|
|
|
|
If an element's `contain` is/contains `paint`, then it will be forced
showing just as its `position` is `relative`.
|
|
if `document.documentElement` is zoomed, Vimium's hints `<div>` are also zoomed,
and then `scrollY` may be not equal with viewport client rect's `top`.
Example:
* make the tab zoom level is 1, `documentElement`'s `zoom` style is 2
* open a page, scroll to the top left corner
* press `f`, and all things are right
* exit LinkHints mode, scroll down for 100px, and then press `f`
* this time all hints has moved down 200px from the correct place
|
|
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.
|
|
When an <a> spans the end of a line and the start of the next line, we
now highlight both parts of the link (instead of just the first).
Also, refactor code for calculating the position of the viewport into a
separate utility in DomUtils.
|
|
Fix UI-component initialization issues (maybe).
|
|
This fixes some UI component initialization issues. It's a long
story...
The problem.
- Go to this page: http://www.thejournal.ie/seanad-election-results-2016-2737768-Apr2016/
- Click one of the links from the "Most Popular" box on the right.
- Navigate back (`H`) and, as the original page is loading, activate the Vomnibar.
In 1.54 this renders Vimium unusable. In `master` this renders the
Vomnibar unsable, but the rest of Vimium usable.
It seems the source of the issue is that we're initializing UI
components too soon. We need to wait until the `readyState` is
"complete".
With this PR:
- The Vomnibar is initialised when the `readyState` is "complete" (in
the top frame only, and only if Vimium is enabled). Requests arriving
prior to then are silently discarded.
- The HUD is also initialized only when the `readyState` is "complete";
however, requests arriving before then are queued. So, if the user
immediately enters insert mode, then the "Insert mode" indicator will
eventually be displayed.
- The help dialog silently discards requests until the `readyState` is
"complete.
I'm posting this as a PR because:
1. It needs some visibility.
2. With this, if the `readyState` *never* reaches "complete", then the
Vomnibar would be unusable. And that's pretty serious.
|
|
There are circumstances when we hav two (identical) vimiumFlash elements
displayed: specifically, when using the waitForEnter keyboard blocker.
So, we should use a class (rather than an id) to style the flash
element.
|
|
This reverts commit c01d7eea8675f9a7d84999777e8de72244d687b6.
Preparatory to implementing an alternative approach.
|
|
|
|
This is part of an effort (as yet incomplete) to track down some CSP
violations we're getting, in this case related to global link hints.
Prior to this, we were seeing CSP violations when accessing the window
subsequently to collecting the hints, specifically when accessing
window.scrollX/Y. Here, we collect the window position immediately,
when initially harvesting the hints.
|
|
When DomUtils.isFocusable() is called from GrabBackFocus-pushState-monitor
it is possible that document.activeElement is not ready. So we should
check.
Here, we check in DomUtils.isFocusable(), because we always need element
to be defined for this test, not just in GrabBackFocus-pushState-monitor.
|
|
We do not need to install separate event listeners for every callback.
Just install one listener and keep track of the callbacks ourself.
This is clearer, and also determines the order in which callbacks are
called. (Although, we don't rely on that currently.)
This also adds a tests.
|
|
There seems to be an issue on this page:
- http://i.imgur.com/PdmUjij.jpg
whereby "DOMContentLoaded" isn't firing. The page structure is unusual
(involving a shadow-DOM element), which might be the source of the
problem.
What happens is that the "DOMContentLoaded" event fires as required, but
the document state is still "loading".
Here, we just say that if the "DOMContentLoaded" handler has fired
once, then we're good to go.
|
|
The reason for doing this is that we will be using the same test to
decide whether or not to register a frame.
|
|
Here's why:
- b7535a604954b5873d825eb66bfecd08f1f2c99b is complicated and complex (O(n^2)).
- With experience, it is not obviously better than what was there
before, and in some cases it's worse.
- b7535a604954b5873d825eb66bfecd08f1f2c99b selects way too much text in
some cases; e.g. on Google Inbox, it selects text lengths in the tens
of thousands of characters. That cannot be useful.
- With global hints, this extra cost (resulting from passing large
objects between frames) is significant and noticable.
- The simpler approach of accounting for text length when scoring
filtered hints (tweaked here: 5cbc5ad702a01a81b98f8c82edb3b6d227c2c7b5)
works better in practice.
|
|
|
|
- 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.
|
|
We can remove these listeners once we're done.
|
|
|
|
This stops us from throwing errors when document, window, etc. end up
being passed into DomUtils.isSelectable.
|
|
This fixes #1964.
|
