| Age | Commit message (Collapse) | Author |
|---|
|
We're not including anything above `main.js.in`, so the top of that file
always ends up as the top of the final user script. We don't need a
separate build step to include it.
|
|
Forgot to comment out the Mousetrap license in the final build file.
|
|
This was for debugging and is no longer needed.
|
|
|
|
|
|
|
|
This is no longer needed now that Peniquitous is a Greasemonkey user
script.
|
|
Now that we've added Mousetrap via NPM, we can remove the one we
installed via Bower and Bower files.
Didn't really need to switch to NPM, but I wanted to get a Mousetrap
dependency that included its LICENSE file so I could include it in my
build.
|
|
|
|
|
|
This will give me access to Mousetrap's LICENSE file.
|
|
Remove the old Chrome extension code now that it works as a user script.
|
|
Don't need Browserify. Just concatenate the user script header and the
compiled `main.js`.
Rebuild the `peniquitous.user.js` user script file.
|
|
Make this a local instead of a global variable. Must have forgotten the
`var` when I first wrote this.
|
|
We're no longer using the `require` imports to include JS files. Instead
we have a template string process. Not as robust, but easier to fit what
the final user script needs to be.
|
|
Since this file has template variables, it's not a real executable
JavaScript file. Add `.in` to the end to make it clear it needs to be
built with Make.
|
|
Instead of copy-pasting the code from the files directly into main.js,
do it in the build recipes.
|
|
In order to import our script dependencies and inject them correctly
into the page, we need to remove the existing IIFEs, append them to the
page in `<script>` tags, and wrap them in custom IIFEs.
If I leave the original IIFEs, they get executed too early, and I can't
insert the scripts into the page correctly.
Got the custom IIFE idea from Max Shawabkeh
(https://stackoverflow.com/users/181765/max-shawabkeh) on Stack
Overflow:
https://stackoverflow.com/questions/2303147/injecting-js-functions-into-the-page-from-a-greasemonkey-script-on-chrome/2303228#2303228
This is working now, but I want a way to build the final user script
without copy-pasting the imports in the main file. Going to work out the
build rules next.
|
|
The keyboard event simulation didn't work. Tried getting rid of
Browserify and including the JS all in one file, but that didn't make a
difference. Committing this for reference.
|
|
|
|
Add Browserify to enable imports. Remove the script insertion code since
it isn't necessary for a user script.
|
|
|
|
Show people what's going on and how to use the extension.
|
|
* Description
* Installation notes
* License information
|
|
MIT license.
|
|
Apparently Wikipedia uses `input[type="search"]`. Might as well include
it since that's probably a common type of input for this use case.
|
|
Move the key code numerical values into a hash so we can refer to them
by name instead of obtuse magic numbers.
|
|
This was used to test out simulating a down arrow key press on the
Google search home page with the field selected and something typed in.
If the first entry in the suggestion drop-down was selected after the
timeout fired, that means it worked.
We no longer need this test code.
|
|
Instead of handling the keyboard events in the content script, inject a
script onto the page that does the key listening and simulating.
This allows the simulation of up & down arrow key presses to actually
trigger the proper page event listeners and allow our custom code to do
the right thing instead of firing a key event in the Chrome extension's
isolated environment and not having anything happening because no
listeners are attached in the isolated environment.
Also inject the `KeyEvent` object from Mousetrap so we can use it's key
simulation feature. Will likely want to extract that into our own custom
code so we're not including a whole script that we only use 20% of or
so.
|
|
Doesn't quite work. We're correctly listening for Ctrl-N/P presses, and
seemingly correctly simulating corresponding up/down key presses, but it
seems that the 'content scripts' can't trigger page events.
See
https://developer.chrome.com/extensions/content_scripts#execution-environment
which describes the "isolated" execution environment of Chrome content
scripts.
Spent a while trying to figure out why this wasn't working. Finally
looked back through my Chrome console history and found out what I did
previously to get it working and it turns out that was the same thing
I'm doing here. Finally had a moment of inspiration that prompted me to
look into the different execution environment thing.
Found a useful Stack Overflow post that descibes how to inject a script
onto the page, which will give me access to the page's context:
http://stackoverflow.com/questions/9515704/building-a-chrome-extension-inject-code-in-a-page-using-a-content-script
Doing that should get this working, so that's what I'm going to try
next.
|
|
Work in progress.
Get all inputs on the page. Bind a callback to their focus event. The
intention is that when the input is focused, I attach a handler to
listen for Ctrl-N/P presses.
Now that I'm writing this and thinking about it though, I might as well
just bind the Ctrl-N/P listeners to all inputs to begin with an be done
with it. Kind of a brute-force way of dealing with it but then I
wouldn't have to keep track of whether or not I've bound those listeners
to an input that was already focused previously.
|
|
* Create limited bower.json file
* Create .bowerrc that tells Bower to use the `lib` directory
* Install Mousetrap for key events
|
|
The scripts need to be defined in the "js" key. All these syntax errors
are because this block used to be a "background" definition but I
changed it to "content_scripts".
|
|
Apparently it takes an array not a hash.
|
|
I like the sound of the '-ous' better.
|
|
Test manifest.json copied and modified from another one of my
extensions. A decent start.
|
