| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This affects filtered hints only.
If a hint is triggered because the user typed the link text, then:
- highlight the link
- but wait until the user types `Enter` before activating the link.
|
|
|
|
|
|
When we `simulateSelect` an input and the selection is at the start, we
move it to the end. This works well for single-line inputs. However,
the UX is *bad* for multiline inputs (such as text areas), and doubly so
if the end of the input happens to be out of the viewport.
This commit simply disables the repositioning of the selection within
text areas.
|
|
|
|
On a XML view page, createElement will create an "Element" object
Otherwise, createElement('div') will get an object
: HTMLDivElement >> HTMLElement >> Element
|
|
oh my god
|
|
|
|
|
|
|
|
This implements @gdh1995's idea from #1796.
|
|
This fixes #1770.
|
|
|
|
If an element with style="display: inline; font-size: 0px;" surrounds
another element with style="display: inline; font-size: apx;", where a
is non-zero, then the inner element and its contents will be visible.
However, the outer element will register height=0 in its clientRects,
which previously caused us to reject these elements. This changes the
behaviour to handle this case correctly.
|
|
This requires passing of an extra truthy argument in order to access the
(generally) unexpected behaviour of sometimes returning the rects of
child elements. All locations in the code that *actually* wanted this
behaviour have been updated to continue using it.
Also add a comment about the unexpected behaviour in the function
description.
|
|
Elements with css `display: none;` never have client rects.
|
|
|
|
|
|
Mainly fix the indentation on comments. Also tweak wording a bid.
|
|
|
|
This only effects link hints with "Use the link's name and numbers for
link-hint filtering" enabled.
We have been matching the *entire text content* of each link-hint
element.
With two (or more) hints, and with one of the elements a descendent of
the other, we have been using the entire text content of the outer node
(which includes the text content of the inner node). This leads to odd
situations where the inner element cannot be selected just by typing its
text, because its text is a substring of the outer element's text.
For example, on Google calendar, the "Today" button shows up as two
hints, one inside the other. Typing "today" never disambiguates the
hint. You always have to hit enter.
There's another nasty example on feedly, where an outer container is
clickable, but its text contains all of the (many) texts of the (many)
contained links. So the hint always has to be selected manually.
Here, when generating the text for an element, we exclude the texts from
any descendent node which has already been considered.
|
|
This restores behaviour to how it was at commit
7cedc5d2481f61f4b0d1cbf99fbd203bb5c68b54.
|
|
|
|
|
|
|
|
These elements throw an error on access, meaning that we can't do an
existence check.
|
|
- convert getCaretCoordinates from JS to CS
- handle x axis in scrollIntoView
- better comments throughout.
|
|
Also, change how vim's "w" is implemented.
Also some code-review/cleanup.
Better dd and yy for gmail.
|
|
|
|
- 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.
|
|
This allows us to select contentEditable elements in the same way as we
can select other inputs.
Fixes #1437.
|
|
There's no point in focusing element if it's already active.
Also, we leave the caret in place, not just a range selection.
isSelected makes the wrong decision if the user has placed the caret at
the start of element. We cannot distinguish that case from the user
having made no selection. Nevertheless, this is substantially better
than the existing UX, which *always* moves the caret to the end.
|
|
|
