vimium/tests/dom_tests, branch 1.52 The hacker's browser. Merge branch 'store-all-settings' into hud-iframe-input-with-store-all-settings 2015-06-25T04:09:36+00:00 Stephen Blott 2015-06-25T04:09:36+00:00 e5faeff7d48a206a080a56a6541963d2d3c86da7 






Guard against chrome being undefined in the HUD iframe
2015-06-10T16:22:21+00:00

mrmr1993

2015-06-02T16:19:24+00:00

73c651465d1395e23daae01b0ae2a3df5b24a789












Fix bug relating to duplicate hint strings.
2015-06-10T15:52:16+00:00

Stephen Blott

2015-06-10T15:39:02+00:00

61764d812a37ca2c29b3b7ddde878f25250abf81

(Not sure when this crept in.)

We need to ensure that we always generate the same hint strings for the
same filter state.  Here, we do this by always using the same mechanism
(@filterLinkHints) to set the hint strings.





(Not sure when this crept in.)

We need to ensure that we always generate the same hint strings for the
same filter state.  Here, we do this by always using the same mechanism
(@filterLinkHints) to set the hint strings.







Make LinkHints a class (LinkHintsMode).
2015-06-09T13:47:39+00:00

Stephen Blott

2015-06-09T13:47:39+00:00

98a3f4c96e8b189ca142f7cccbc1ef995c158b9d

Functionality wise, this is a no-op.  However, since we now create a new
LinkHintsMode object on every "f", we don't need to be so careful about
resetting the state on exit.





Functionality wise, this is a no-op.  However, since we now create a new
LinkHintsMode object on every "f", we don't need to be so careful about
resetting the state on exit.







Remove LinkHints.init()...
2015-06-01T08:46:43+00:00

Stephen Blott

2015-06-01T08:46:41+00:00

e8476682362b9648aba874e8581fe9076479f734

LinkHints.init() isn't doing anything.





LinkHints.init() isn't doing anything.







Re-work unified settings.
2015-06-01T06:56:02+00:00

Stephen Blott

2015-06-01T06:04:43+00:00

c62ffa33ad5230b89f44cb8f3268e6a4e48afd52

This is a minor re-working of #1705 from @mrmr1993.

The main changes are:
   - Simplify initialisation logic.
   - Always initialise Settings immediately and automatically (ie. don't
     initialise Settings separately and manually in the background,
     content scripts, options and tests).
   - Get rid of addEventListener (it's only being used for on "load").
   - Add Settings.use() in its place.





This is a minor re-working of #1705 from @mrmr1993.

The main changes are:
   - Simplify initialisation logic.
   - Always initialise Settings immediately and automatically (ie. don't
     initialise Settings separately and manually in the background,
     content scripts, options and tests).
   - Get rid of addEventListener (it's only being used for on "load").
   - Add Settings.use() in its place.







Rewrite settings as a tight wrapper around Settings, tweaks for tests
2015-05-31T16:51:01+00:00

mrmr1993

2015-05-31T15:35:09+00:00

0de6b076271b673d0e1dcc2b74b2ddd1646bf08e












Verify keyword for custom search-engine activation.
2015-05-29T16:14:25+00:00

Stephen Blott

2015-05-29T16:06:55+00:00

97bfe5f039ae9044fc634448ad3a97b1cdc05792

For ...

    map s Vomnibar.activate keyword=g

... we verify that "g" is indeed a custom search-engine keyword before
setting it.  If it is not, we output a console.log message and launch a
vanilla vomnibar. (An alternative would be to bail.)





For ...

    map s Vomnibar.activate keyword=g

... we verify that "g" is indeed a custom search-engine keyword before
setting it.  If it is not, we output a console.log message and launch a
vanilla vomnibar. (An alternative would be to bail.)







Merge pull request #1616 from mrmr1993/detect-inline-inline-fontSize-elements
2015-05-27T16:31:03+00:00

Stephen Blott

2015-05-27T16:31:03+00:00

677fbc502fcd70fcb5700c04cdfdd76360b43c7e

Fix for #1554.




Fix for #1554.






Refactor to avoid potential race condition.
2015-05-26T06:19:52+00:00

Stephen Blott

2015-05-26T06:19:52+00:00

6b49dd27cb20ef5f830b1107b39480201796885d

I haven't seen this happen, but...

It could be possible for the iframe's contents to load before this
callback is called (on nextTick), in which case the "load" callback
wouldn't be called.  So we delay setting the iframe's source until
nextTick has elapsed.





I haven't seen this happen, but...

It could be possible for the iframe's contents to load before this
callback is called (on nextTick), in which case the "load" callback
wouldn't be called.  So we delay setting the iframe's source until
nextTick has elapsed.