brandon1024 / find Goto Github PK

The new button images were accidentally reverted, must be brought back.

When proceeding through multiple searches, if a website like Stack Overflow has a header, our auto scroll into focus will sometimes place the orange highlighted search behind the website header. Suggested fix would be to possibly vertically center orange highlights.

After publishing the extension in the chrome web store, I noticed that when searching for the extension, the 'Runs Offline' flag excludes our extension when it should not. I believe this is simply a matter of adding the flag in the manifest.

Build the highlighter.js class

images need to be referenced in /resources folder

1. Have UI appear separated from extension button
2. Have Search Field
3. Have Search Button

note- At this point, none of these components will have functionality attached to them.

To prevent malicious Chrome extensions from installing other extensions and changing user settings, developers disabled chrome extensions from injecting Javascript into any webpage with the url chrome:// or https://chrome.google.com/webstore/category/extensions. As a result, our extension appears to be unresponsive on these web pages, and this could confuse users who are not familiar with this extension limitation.

It would be beneficial to display a small message to notify users of this.

I can see it now: people will complain that they aren't sure exactly what syntax is supported by our extension.

I had an idea to display the JavaScript regex literal notation directly in the search field. You wouldn't be able to modify it, but it would give an idea as to what can be inputted in the field.

When the popup is displayed, the search field would contain //g, or if a previous search was stored, /prev/g. The //g characters would be light gray, and any attempts to select the characters or remove them would just place the cursor between the slash characters.

It might also be a good idea in the future (maybe V2) to provide a simple how-to-use in the app itself. Maybe pressing CTRL-h expands a small view with a description.

If, for instance, the text ff appears in a web page and using the extension we search for the letter f, this counts as two separate occurrences of the regex. However, the entire string ff is wrapped and highlighted as a single occurrence of the regex.

Example:

<div id="_eEe">
     <span id="3f42b5dd-a46d-258c-e399-0c883f185ce1">Google.ca o<span class="find-ext-highlight-yellow find-ext-occr0 find-ext-highlight-orange">ff</span>ered in: </span><a href="https://www.google.ca/setprefs?sig=0_ugolniklP1E8Kn06zi_PE0qj1o4%3D&amp;hl=fr&amp;source=homepage" onmousedown="return rwt(this,'','','','','AFQjCNHY0wvgVzK0ANCLM6pkZ33mUpTczg','','0ahUKEwi4hPz0xYfWAhWJ1IMKHVo6APgQ2ZgBCAw','','',event)"><span id="8a3391f2-9ffd-ed44-0844-7032c51004ab">Français</span></a>
     <span id="7c8bbe3d-f2d2-29ee-c82a-ea6b42283f96"> </span>
</div>

The search field in the extension popup is smaller it should be. Using devtools, I noticed that the field has a width of 127px, while the parent table cell has a width of 175px. The field should fit snuggly in the parent cell.

Improve the look of the extension buttons, to look similar to native find-in-page tool.

For updating the highlighting, and storing of current SearchField text, both 'onkeypress' & 'onkeyup' will not be invoke an event listener in the case of selecting predictive text, or copy+paste.

On the other hand, changing the SearchField event listener to be sensitive to 'input' simply catches all changes to the input field. This can simply be done in any outstanding feature branches, and implemented moving forward.

• F37_InputFocusAndSave
• F9-Build-Backend-DOM-Search

When at the last index, pressing next or enter should wrap to the first index.

Decrease Search Bar's margin to look more like ctrl+f search bar.

After installing the extension through the Chrome Web Store, the CTRL-SHIFT-F keyboard shortcut does not appear to fire. In order to open the extension using a keyboard shortcut, we need to manually change the extension settings in chrome://extensions.

In MacOS (and possibly linux?), the Chrome find-in-page function is slightly different from Windows. Is it possible to support different views depending on OS, and should we?

The buttons will be modified to appear more like ctrl+f buttons

While testing the extension on google.ca, I noticed that searching f returns a total of 489 occurrences. This is incorrect, and it appears as though this is due to the extension indexing occurrences in style elements.

While debugging, I also discovered that the content script is not correctly excluding hidden content.

Have the "X" button close the extension on-click.

As it stands, when the extension is launched by using keyboard shortcuts or by clicking the browser action, the search input field does not request focus, requiring the user to click the extension to input text. The text in the field should also become selected once the extension loads.

Saving the previous search will be fixed in a separate issue: #40

Remove border from search bar, possible increase size also.

Have the ability to open the extension with ctrl+shift+f.

Whenever the extension is closed, we will want to maintain the previous value in the input field. Upon re-opening the extension, the last value should be highlighted and the input field in focus.

When text is highlighted in the footer of a page (in the bottom 100px of the page), our seekHighlight function scrolls slightly above it, which hides it. Originally, this was done to ensure that highlighted text appears 100px down from the top of the client window and to ensure that text doesn't appear behind a webpage top banner.

Currently, in seekHighlight, window.scrollBy(0,-100); is executed regardless of where the text is in the page. However, if a highlight appears in the bottom of the page, this should not be executed.

It's time for an options pane. This will allow users to personalize the extension. See V2: Options Page for more information.

Useful Documentation:
https://developer.chrome.com/extensions/options

Instead of using image icons for the function buttons in the popup, we should replace them with scalable vector graphics. This will make them scalable, crisper, and better all around.

Text field needs to have more padding between it, and the left side of the body.

Beta Feature: When something is highlighted in the web page, and the extension is opened, whatever is highlighted in the web page should be automatically entered in the search field. This is common to IDEs.

Beta Fix: Presently, our extension looks through all text groups in a web page. If the page has sections that have the style attribute "display: none;" or "display: hidden;", the text will not be visible, and thus our extension should not find it.

Look into adjusting project hierarchy into something more professional and clean.

Currently a seperate .js file is being used for the close button functionality. Merge this into the index.js file

Should look at replacing the old find+ icon with an updated icon, with alpha transparency and nice colors.

Add information and formatting to README.md to provide information about our extension, how to install, and how to contribute.

Following google's style guide, should rename index.js to popup.js

Porting the extension to Firefox will increase the reach of the extension.

References:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Porting_a_Google_Chrome_extension
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs

When searching a web page that has scrollable divs, the occurrence is not shown in the scrollable section. Our scroll function only scrolls to the location in the window.

In order to do this, we will likely have to walk the DOM upwards, scrolling each element into view.

Build the javascript framework for searching the DOM for a regex.

Tasks:

• Create a framework allowing the extension to communicate with the web page.
• Add jQuery and jQuery UI to lib folder
• Create a background script, connected to the popup through a long-lived connection, that will handle most of the business logic behind the extension.
• Build a script to parse the webpage into pieces of text with references to the webpage DOM, allowing the background script to search through the text and highlight text on the page.
• Create endpoints in background script to hand over information to highlighter for highlighting text on the web page.
• Popup UI fixes and improvements
• Add support for remote and local text files
• Complete Highlighter script.
• Final code refactor.
• Dev testing to iron out small issues
• V2: Show occurrences for visible text only

• Font size should be made slightly larger
• and changed to a dark shade of grey to match ctrl+f

Complex webpages with dense DOM content pose an inherent performance concern. Our extension must be as performant as possible to keep responsiveness as strong as possible. In the case of our DOM object model builder, the algorithm is quite intensive and relies on a number of checks to ensure text is grouped properly. Highlighting is also another area that must be as performant as possible.

While testing our extension on a GitHub diff, I noticed that responsiveness was significantly lessened. Through testing, I discovered that GitHub diffs have a huge number of elements. Our DOM model object builder function made approximately 6000 iterations, compared to less than 2000 on a large Wikipedia article.

Using JavaScript performance profiling functions, I recorded that in a GitHub diff, our extension took on average 375ms to build the DOM model object (based on building the object eight times [365, 366, 379, 388, 376, 392, 375, 359]).

Looking deeper, I realized that we use jQuery in the content script to wrap elements with our markup. jQuery is known for being very slow compared to vanilla JavaScript.

So, to improve the performance of our extension, it is best that we limit our use of jQuery to areas where performance is less of a concern. For instance, using jQuery to modify our extension popup for a more dynamic feel is perfectly adequate. However, jQuery should not be used when building the DOM model object or highlighting all occurrences on a page.

On wider monitors, the normal ctrl+f tool will become much wider than our original sizing.
Can either add 1 or 2 @media .css changes to increase bar width depending on screen size, or make dynamic for all screens with using 'em' instead of 'px'.

When hovering over a button, a text bubble should appear displaying the name.

While testing the extension, I noticed that some of the markup that we inject into the webpage is not removed correctly. This occurs when our markup does not contain any children nodes. The reason this occurs is because the jquery function .contents() will return an empty jQuery object when an object does not contain any children nodes. Performing an unwrap() on this object will have no effect.

This issue surfaced after an earlier fix: https://github.com/brandon1024/find/pull/70/files#diff-ce3bdf8c52716d2048208c2ad1279742R130

To be addressed:

• If our markup does not have any children nodes, it should be removed correctly in our restore() function

While debugging #9, I noticed that the wrong regex is being sent to the background script. Upon further investigation, I believe I have discovered the cause. When the onInput event is fired, a message is sent via the Message API through our flow. My guess is that when the event is fired, the text in the search field still has not been updated, causing the JSON payload to have invalid information.

If this is the case, introducing a small delay would fix this, but this isn't exactly desired because this would introduce a race condition between our Message API and the HTML/JS.

We need to supply a:
128x128 icon for install
48x48 icon for extension page
16x16 icon for extension button

Beta Fix: While testing the extension on Wikipedia, I noticed that the whitespace character   appeared often in the DOM, which made searching more difficult.

We should add support for treating these entities as simple characters so that the regex search engine can do its magic. We should provide support for ASCII characters only, all other characters can be interpreted by their entity name when needed in the search.

So, entities between   and ~ should be treated as their respective character representations. We will NOT support ISO-8859-1 characters and symbols, or any other miscellaneous symbols.

An option should also be available to ignore html character entities, i.e. treat their codes as characters themselves.

Once the highlighted DOM is set, pressing 'Enter' should proceed to the next valid search, while pressing 'Shift+Enter' should proceed to the previous.
Additionally, pressing 'Ctrl+Enter' should close the extension.

Need to update GitHub readme to reflect the new release.

When clicking on the extension button, our UI appears connected to the extension button. Would like to make it more like the ctrl+f search bar.