A Temporary Home

I uploaded version 1.1.0 to the Extension Catalog three days ago, but the new Opera version must have dramatically slowed down their approval process. Until it's updated there, you can find the final version in the Public Beta uploads HERE.

The Next Version

MakeLinks will be moving from version 1.0.5 to 1.1.0. The method for automatically inserting icons/links and the method for selecting nodes has been replaced with a streamlined and safer process. This, also, now means the overhead for parsing very large documents should be minimal.

Finally Found

I finally found a safer method for injecting links and icons. This means icons and links will be in the proper place and won't require an option. Since this is a major change, I will be testing this for a few days before uploading it as an official update.

More Current Status

I was able to add the options (listed in the previous post) to the current beta version (1.0.4) of MakeLinks. Also included is the requested option to use clickable links instead of clickable icons. What I don't like about this option is that you can't tell when the link is part of the page or added by the extension. If something breaks, it will be hard for a user to detect the difference between a broken page and a conflict created by the extension.

As before, there's a warning when using this new option since it may cause a conflict on the target page. When operating in the "next to addresses" mode, the target page code is inserted in the middle of the existing code. When not, the code is virtually moved after the element containing the link. It will not split important code, but it also may appear further than expected from the link. The good news is that causing a conflict is rare, so it's really less of an issue than expected. The 'Excluded Websites' list is also another safety feature that makes any conflicts even less of an issue.

If no problems are found in the next few days, the current Test 3 version will be released as an official version.

Current Status

Version 1.0.2 is out but version 1.0.3 already waiting for publishing. Version 1.0.3 is a quick-fix for the 'automatic' configuration option being broken and for the icon being manipulated by the target pages style sheet.

I'm working on a new version (1.0.4) currently with a small set of goals. I'm working to further improve the link detection process. This will allow me to support the automatic detection of links in the form of www.example.org without requiring a path after the hostname.

I've had two feature requests. The first is an option to disable the popup. Since MakeLinks can work in automatic mode, this makes sense. The second is an option disable the plugin for specific sites. I'm not a fan of this second option because I'd rather just fix the extension so that it doesn't conflict with other sites, but this might not be a practical possibility. There will always be a period of time between the conflict and me being able to fix it or work around the conflict. A stopgap solution seems to be needed.

A Compromise Part 2

I was able to re-add dirty link detection for the automatic mode in the last Public Beta upload. To test this, search for 'http://www.example.org' on Google where search terms are often places in bold text. The highlight method for detecting links already has this feature since it can detect the highlighted text without any formatting.

In the last upload, I think I've made the 'next to addresses' option very stable and fast. While it's still possible for it to corrupt code, since it actually changes the page, I've seen very few problems besides some minor layout changes. Without this option, the icon links are actually appended code - which means their placement can be further away the expected location.

Unless any further problems are found, v1.0.2 Test 4 will be the officially released version.

A Compromise

The newest upload (Test 4), is a compromise to improve speed, compatibility, and functionality. The previous test interfered with the normal operation of some pages, especially complex web pages. The 'next to address' option was rewritten to prevent this situation.

This changes mean that detecting 'dirty' links will have to be implemented some other way, but it is possible to do using the new method. This will likely be re-added in the next test version.

Finally, automatic detection is now triggered sooner. The extension is triggered to execute before some non-essential items, like images, are finished downloading. Pages with a large number of these items to download would stall the execution of this function.

Yet Another Public Beta

In the current beta version upload (v1.0.2 Test 3), I've added a new feature and fixed a popup display issue.

The new feature to automatically add links directly next to the web address was initially problematic. This method requires a completely different way of accessing the web page. Without special handling, data could be inserted into the wrong places and this would interfere with the page's code or visual layout. This has been improved upon in the newest upload to be less of a problem.

Using this new method, though, allows for me to detect and handle 'dirty' links. These are text addresses that are split into smaller pieces using formatting tags, though the text still appears to be a single item. For example, part of the link may be in bold. This type of detection is not possible using the default link detection method.

Lastly, the popup would sometimes not show or function on certain web sites [like avclub.com]. Sites that used layers to show some items above or below others would be affected. This has been fixed by making sure that the MakeLinks popup is defined to be above all other layers.

The Newest Public Beta

In the newest Public Beta, I've implemented three new changes.

The first option will split a link into breadcrumbs, when the highlight mechanic is used. Each section of the link becomes clickable to optionally only use part of the web address. Though I think this a very useful option, I've decided to disable it by default since it does change a major feature of this utility.

The second option is based on user feedback. This option will detect missing or incorrect "http://" prefixes and correct them. Currently, if the address has no protocol prefix at all, a link will only be detected if it is followed by a path (eg www.example.com/stuff). This prevents most false positive detections when two words are separated by a period, like "document.write".

The last item is a fix. The detection of web addresses has been improved. This removes many false positives as well as greatly improves the new option correct detection of addresses missing the prefix.

The Next Changes

Now that MakeLinks has a Preferences page, I can add more optional features that allow for flexibility without interfering with the normal work-flow. Options that may interfere will not be enabled by default.

I've already had a request to add support for links that do not begin with the http prefix. Addresses like "www.example.com/stuff" are not currently detected, since this would require a secondary and more restrictive search to prevent false positives. The current detection for "http:" addresses is currently very lax, to the point of actually being incorrect.

Another thing I've noticed is that addresses are often found enclosed in parenthesis as follows: (see http://example.com). Currently, the trailing parenthesis will be included in the link though this is not likely the desired behavior. An option to detect and correct these addresses would work well.

I've, also, been thinking about a breadcrumbs option in the popup. This would split an address into separate clickable parts, instead of manually removing part of the address after clicking it.

A New Beta

In the current Public Beta v1.0.1 Test 1 upload, I've added the requested feature for an option to enable automatic detect of links. As said below, it is disabled by default because it may be process intensive on slower systems and it inserts content to the target page.

When links are detected in Automatic mode, a small icon link is place after the element containing the web address. Unlike the highlighting method, this will fail to detect web addresses that are split up with HTML tags. For example, if part of the web address is enclosed in Bold tags, part or none of the address may be detected. I've found no workaround for this issue besides manually highlighting these items. Also, the location of the icon may appear much further away than when using the highlight mode since a reliable means of locating the web address position seems to be not possible.

I've also added an option to detect text web addresses enclosed with link tags. This is an experiment, since these items are already clickable links. I may remove this options for the official release since it effectively only adds a visual indicator.