| Age | Commit message (Collapse) | Author |
|---|
|
|
|
getViewportTopLeft: support zoomed static documentElement
|
|
InsertMode should not handle key events if document.body is editable
|
|
Use event argument instead of global event object
|
|
|
|
|
|
Replace depreciated APIs
|
|
|
|
The documentation suggests that 'highlighted' is equivalent to
'selected'. However, multiple tabs can be highlighted in a window -- in
fact, everywhere 'selected' was used, we wanted the unique active tab.
|
|
|
|
|
|
|
|
|
|
|
|
For example, the host JavaScript may create an "about:blank" iframe with a
`content-editable` `body`, and then:
* the parent frame may handle `Escape` key events by itself
* but now, Vimium always grabs `Escape` events
* and tries to exit `InsertMode`
* although `document.body` is still current `activeElement`
after `body.blur()`
* as a result, neither the parent can receive and handle wanted keyevents,
nor Vimium will succeed in returing back to NormalMode
|
|
|
|
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
|
|
Fix (another) infinite-scroll issue.
|
|
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.
|
|
Guard against element.tagName not being a string.
|
|
Example page: http://codeforces.com/contest/752/problem/B.
There, `element.tagName` is an element with `name` `tagName` (not a string). Here, we guard against that case.
Fixes #2305.
|
|
Try the following....
- load page
- `/`
- type some junk which matches nothing
- `Escape`
We expect to leave find mode. Instead, we have to hit escape again to
get out of find mode.
Here, `focusNode.focus()` is not a function.
|
|
|
|
|
|
Don't set the update_url by default.
|
|
Add match-about-blank permission.
|
|
New command option to enter normal mode
|
|
Makes sure all custom link hint characters defined in settings are lowercase
|
|
This allows Vimium to run in iframes with `about:blank` URLs.
Fixes #2360.
|
|
|
|
|
|
|
|
Float find-mode matches to the right.
|
|
This floats the "5 Matches" text in the find-mode HUD to the right.
This looks nicer, because the "5 Matches" text doesn't move as you type.
As it happens, it also fixes an issue which arose a few months ago (for
unknown reasons) with the positioning of the cursor in find mode. The
cursor position was becoming "jammed" after the first character as you
type.
|
|
|
|
|
|
|
|
This means that we get the new tabs in the same order as they are
specified in the key mapping.
|
|
Example:
map a createTab http://edition.cnn.com/ http://www.bbc.co.uk/news
which creates two new tabs, but preloaded with these specific URLs.
`2a` creates four new tabs, two copies of each.
Limitation:
- We cannot control the order of the tabs, so we might get CNN then BBC,
or BBC then CNN. This happens because command options are stored in
an object, and we cannot control the order of the keys.
Also, with:
map a createTab http://www.bbc.co.uk/news http://www.bbc.co.uk/news
we only get one new tab (same reason as above).
|
|
Keep the option list (in addition to the parsed command options) because
some commands may depend upon the command option order. One currect
example is #2318.
|
|
Rework key-mapping parsing and help-dialog HTML
|
|
(Because we're scanning backwards throught the mappings, we shouldn't
overwrite an existing mapping.)
|
|
|
|
Previously, the dynamic HTML for the help dialog was generated on the
background page. The HTML itself was tangled in with program logic.
Here, we move all of the HTML to HTML5 templates; also, we build the
help-dialog contents in the help dialog itself, not on the background
page.
Note: #2368 is included here too.
(Background: I'm trying to clean up some of the command and help-dialog
logic in preparation for addressing the issue of how to document command
options, see #2319.)
|
|
There are two changes here:
1. Treat built-in key mappings and custom key mappings in the same way;
that is, we prepend the built-in mappings to the custom mappings and
then parse them all together. This results in a number of
simplifications due to previous duplication of logic and the elimination
of special cases.
2. Parse key mappings in reverse order, so we can just ignore key
mappings after first encountering a key sequence. So, `map`, `unmap`
and `unmapAll` are all treated in more or less the same way.
This is preparatory to reworking some aspects of the help page. In
particular, regardless of the order of maps, unmaps, etc., this approach
makes it easier to find the mapping in effect for a key sequence (and be
able to recreate the order of those mappings).
|
|
Move SearchEngines to bg-utils.coffee.
|
|
|
|
|
|
|
