vimium/content_scripts, branch 1.55 The hacker's browser. Guard against non-string values. 2016-05-12T06:49:43+00:00 Stephen Blott 2016-05-12T06:49:37+00:00 a1c00c38abee530f84572c36c7422e4ee793316b If the link's value is not a string, then the previous version of this fails. The new test will be false for such links. 
If the link's value is not a string, then the previous version of this
fails.  The new test will be false for such links.
Revert "Improves next/previous links by targetting button elements and adding single left/right angle quotation marks" 2016-05-12T06:21:07+00:00 Stephen Blott 2016-05-12T06:21:07+00:00 22f0ed9c3c63ecbc4fc2413dc5235a9489d9cf25 This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff. This reverts #2117. This breaks next/prev on Reddit (it chooses a different link). Reddit is an important site, so we should unwind this for now. Mention @sco-tt. 
This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff.
This reverts #2117.

This breaks next/prev on Reddit (it chooses a different link).

Reddit is an important site, so we should unwind this for now.

Mention @sco-tt.
Merge pull request #2118 from smblott-github/fix-ui-component-init-issues 2016-05-07T03:37:36+00:00 Stephen Blott 2016-05-07T03:37:36+00:00 d00cc696c8e43b1b0298bce61fa18e22d78f270d Fix UI-component initialization issues (maybe). 
Fix UI-component initialization issues (maybe).
 install the real selectionchange listener after window.find 2016-05-05T10:55:47+00:00 gdh1995 2016-05-05T10:55:47+00:00 f387d2e0d743a18b5983ff5debb74e2634cb5f87 






Removes unnecessary parentheses and makes precedence of || and && explicit
2016-05-02T21:59:38+00:00

Scott Pinkelman

2016-05-02T21:56:49+00:00

7aa53edf5776370b6da7ddfb1dae9e7017693f59












Make findAndFollowLink look at element values so <input> can be used for next/prev links
2016-05-01T14:26:09+00:00

Scott Pinkelman

2016-05-01T14:26:09+00:00

e347a3735d30a1a596c0b1958d584b07d79e399f












Fix UI-component initialization issues.
2016-04-28T12:55:08+00:00

Stephen Blott

2016-04-28T12:51:44+00:00

f83e99fd42a4cf412c79fb15c58f59c105c25723

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.





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.







Make vimiumFlash a class.
2016-04-28T05:51:35+00:00

Stephen Blott

2016-04-28T05:51:35+00:00

fc8519e4e3a770253a35f1af7546d432f64392ea

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.





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.







Improves next/previous links by targetting button elements and adding single left/right angle quotation marks
2016-04-26T19:01:49+00:00

Scott Pinkelman

2016-04-26T19:01:49+00:00

ee8c235aeaf52d2bc867a00c37731690e337c7ff












Merge pull request #2107 from smblott-github/modernize-help-dialog-styling
2016-04-26T06:42:03+00:00

Stephen Blott

2016-04-26T06:42:03+00:00

26667165720a81aee49e959b7bc930b0cd959eb4

Modernize help dialog styling




Modernize help dialog styling