1 | 2 | 3 | 4 | 5

16 - 20   [24]

Next Link Misleads Logs

Also relates to Web Standards and Accessibility, Apache

This is a very annoying quirk that took me far too long to track down! When calling pages on my test platform using a new caching system and a package of builder classes for parsing XML based metadata a second call for a page was being made to the server. In short, the page in question was that defined as next in the relative links:

<link rel="next"
           href="/uri_of_page/"
           title="Description of the page/>

At first I thought this was down to a coding error in one of the PHP classes. Fortunately browsing the HTTP headers and a timely flick through the HTML 4.01 Specification abated my growing frustration. The specification states the following for the next link type:

Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time. http://www.w3.org/TR/html401/types.html#type-links

Well it is the second sentence that is clearly significant here. The second call for a page to the server abides to the above recommendation. In fact on further scrutiny I discovered this problem is distinctive to Mozilla family which utilise the link toolbar (I did not take further time out to test on Opera).

I see a major conflict in this. The relative links have been adopted as important elements for accessible navigation and are a recommended technique for achieving several guidelines in the WCAG at level 2 and 3. Yet, as long as user-agents abide to the above statement regarding the next link type, there is a conflict of interest between attaining accessibility and maintaining reliable web server logs! This is especially so with Webalizer, the most popular open source software for producing tabular and graphical statistics from Apache's Common Logfile Format. For each pre-loading call to the webserver will register an additional page hit for that page in the access log. If the user actually visits the page via the next link a second page impression will be registered!

Fortunately for once, Exploder is beneficial here, since it has no idea whatsoever about relative links, and therefore the above over-logging will not occur. Sadly this may explain why on a number of my clients sites (this site included) Mozilla and co are falsely striving into the lead on the browser stakes! One solution may be to flush out the pre-loading entries by looking for calls for two separate pages from the same IP address within a second or two of each other. If I can find a minute may call for some Awk and Sed.

Posted on May 21, 2004 at 23:42:26. [Comments for Next Link Misleads Logs- 0]

Choosing Firefox Extensions

Also relates to XUL

This post is now out dated. I have posted a similar posting relating to Firefox 1.0PR and my selection of the best extensions here.

Following on from my previous entry on the new Opera pre-production release, I just want to take a quick look at the extensions that expand the functionality of Firefox. Several friends and clients have test run Firefox (and previously Firebird) over the last 12 months, some even making it their regular browser. Yet nearly all of these users appear baffled when, on booting up this amazing browser that I am raving about, they are faced with a minimalist and featureless interface. Of course I point them to the Extensions repository and recommend a few useful addins to get them on their way, yet on revisiting clients months later, they are still using the minimal install or (worse still) have resorted back to the Exploder family!

I feel part of the problem here is that many users have an expectation of what a web browser is, based on their experience with Exploder, and so when a new browser is presented to them it is just regarded as Exploder in another guise. Plus of course lack of business time to install extensions (along with the profile backups and chrome editing this generally entails). This is not all doom and gloom though, since Firefox is after all a Technology Preview and not intended for direct public consumption.

Personally, I am a Firefox fanatic! I cannot get enough of this browser and its multitude of extensions. Right now I have four profiles set up, each serving a different purpose: manual reader; development browser; blogging browser; and research browser. On top of this I have two test profiles I use to put new or updated extensions through their paces to ensure none of the established profiles get mangled. The one rant I do have with the current installation process is the occasional extension (bar the script libraries) that automatically throws itself into the application directory without first confirming this is o.k. with me. Several times this has led to a complete reinstall due to the extension interfering with extensions in another profile. Ideally the XUL developer in question could specify when an extension will behave like this.

Anyway, enough of the rant. The intention of this entry is to list those extensions I have found most useful, in part for my own reference, and so I can point clients and friends to this entry to give them an idea of extensions worth taking time out to install. (Extensions marked with an asterisk * may not offer installation to profile directory).

  • MozLib and JS Lib - Essential base script libraries for some extensions. (Automatically installed to application directory)
  • All In One Gestures - Mouse gestures are a must, and this offers extensive options.
  • Link Tool Bar - Link metadata is essential for assistive technologies. This brings the same usability to the browser.
  • Paste and Go * - Use it once, and you will not be able to do without it!
  • RSS Reader Panel - A simple to set up and use syndication interface based around a bookmarks folder of choice.
  • Advanced Search Side Bar * - Why search just Google when you can search them all at once!
  • Tabbrowser Extensions - On installation choose the session management option too to reload collections of pages with one click.
  • Quick Note - I had some conflicts with early releases of this but it seems stable now, and an efficient way to collate data through the context menu.
  • Toolbar Enhancements - Brings back all those missing buttons. Plus create your own tool bars and place them any which way.
  • ConQuery - Quick search on selected text through the context menu.

Here are a couple of aesthetic extensions which add minimal but nice functionality:

  • Cute Menus - Just adds extra icons onto the context menu.
  • Grippies - Click on, click off to show hide side bar.

Essential developer extensions that I cannot do without:

I have had all of these running under the same profile at some time or other with no conflicts. I would strongly recommend creating a new profile whenever you install new extensions beyond these, to avoid damaging current working profiles. I normally take the following process:

  1. Create two new profiles (profile_basic, profile_ext). Run "C:\Program Files\Mozilla Firefox\Firefox" -profilemanager from the command line (note the path to Firefox will depend on your installation).
  2. Copy all files from the normal profile to one of these new profiles (profile_ext) - this will be the test profile to ensure no conflicts occur with the current extensions in the working profile.
  3. Make a backup of the chrome folder in the Firefox application directory - this ensures recovery if the extension unwittingly installs in the application directory.
  4. Start up Firefox with the basic profile - "C:\Program Files\Mozilla Firefox\Firefox" -p profile_basic. Install the extension. Provided it prompts where to place the extension, choose profile - normally this just entails clicking OK.
  5. If all works fine, shut down Firefox and start up again with the extended test profile - "C:\Program Files\Mozilla Firefox\Firefox" -p profile_ext.
  6. If this works fine and the extension is installed in the profile and not the application directory, then finally install it into the working profile.
  7. The two test profiles and backed up chrome directory can all be removed.

I am not suggesting this is a fail safe method, but after several hours lost reinstalling the application, profiles and extensions following an impulsive installation of a far from stable extension, I take caution when installing new extensions into my working profiles until I have confirmation of their stability. If the advanced test fails [6] yet the basic test succeeded [4], then a conflict exists with one of the currently installed extensions. If you want the new extension, the best option is to create a new profile for it. This is how I have come to have several different working profiles serving different purposes. It is also a perfect excuse to flavour each profile with a different theme. With a low RAM running machine I tend to go for the grayscale themes like Breeze and Smoke.

I hope perhaps this entry will point a few more people towards experimentation with Firefox. Believe me you will not look back once you start playing!

Posted on Apr 24, 2004 at 14:11:55. [Comments for Choosing Firefox Extensions- 1]

Welcome Back Breeze!

This post does not relate to any other topics

Nice to finally have the Breeze theme back on my Firefox.

Posted on Mar 07, 2004 at 20:47:15. [Comments for Welcome Back Breeze!- 0]

XUL Preview In UltraEdit

Also relates to XUL and IDEs

While the XUL Console discussed in the previous post is a useful tool for learning the XUL language by example with instant testing, it embeds the <window> within the XUL Console itself, so GUI display is not accurate. This can probably be overriden with JavaScript, but since I am still in the early days of XUL discovery focusing on the markup and CSS I decided to set up a Tool Configuration in UltraEdit instead, to allow XUL applications to be run straight out of the editor. First the XUL package needs to be registered in installed-chrome.txt under the Mozilla root:


content,install,url,resource:/chrome/my_xul_file/content/
locale,install,url,resource:/chrome/my_xul_file/locale/en-US/
skin,install,url,resource:/chrome/my_xul_file/skin/

For some inexplicable reason I also found I had to manually enter the skin framework into the application chrome.rdf file:


<RDF:Seq about="urn:mozilla:skin:modern/1.0:packages">
  
  [..]
  
  <RDF:li 
    resource="urn:mozilla:skin:modern/1.0:my_xul_file"/>
</RDF:Seq>

[..]

<RDF:Description about="urn:mozilla:skin:modern/1.0:findfile"
               c:baseURL="resource:/chrome/my_xul_file/skin/">
  <c:package resource="urn:mozilla:package:my_xul_file"/>
</RDF:Description>

The installed-chrome.txt file should have done this for me. Anyway, with the package registered, an UltraEdit Tool Configuration can be configured with the following command line:


"C:\Program Files\mozilla.org\Mozilla\mozilla.exe" _
  -nosplash -chrome "chrome://%n/content/%n%e"

Where _ is a line continuation. By adding the tool to the menubar, my XUL previews are just one click away. Note that if another instance of Mozilla is running at the same time, the preview will not update since it will use the chrome files from the instance that is already running. So I view the XUL Tutorial and Programmer's Reference in Firefox while I work on my XUL.
[ Micro who?! ;) ]

Posted on Mar 07, 2004 at 20:46:32. [Comments for XUL Preview In UltraEdit- 1]

Venkman Debugger To The Rescue

Also relates to DOM Scripting and XUL

I have had some problems getting the XUL Console to work on Mozilla 1.6. I caught a brief glimpse of the sample widgets the first time I ran it, but since then the console has been blank and totally functionless. Since I was keen to utilise the downloaded version of Alice Corbin's Periodic Table to help learn the markup, and with lack of bug reports for the console on MozDev, I decided to try and debug it myself.

The JavaScript Console told me the error was an unrecognised path in the file chrome://mozlib/content/lib/js/io/file/instantiator.js, part of the MozLib extension library. So, enter the Venkman JavaScript Debugger. This was the first time I had test run this for genuine reasons, but it is relatively easy and intuitive to get going.

  1. Open up the Debugger.
  2. Uncheck the Exclude Browser Files option in the Debug menu since the target was part of the chrome.
  3. Start up the XUL Console.
  4. Locate the file instantiator.js in the Loaded Scripts window and set a break point on the line the error was occurring (Line 73).
  5. Attempt to perform a function in the XUL Console.
  6. The Debugger stops on the breakpoint, and the variable at fault can be examined.

The error was clear, the directory path to Mozilla was set in Windows format with escaped backslashes, while the additional path to the particular file (in this case the samples) was set with forward slashes. (One of the many Windows banes!). Well, time was not available to delve deep into the MozLib library and find out where this was originating, so I settled with adding a regular expression snippet at this point to correct the path and see if that would work.


var re = /\//g;
var result = path.replace(re, "\\");
path = result;

The problem was resolved and now the XUL Console is functioning perfectly. I could have quite easily passed an hour reinstalling the extensions and editing chrome files in an attempt to fix this, but in 5 minutes Venkman had pointed me in the right direction and the problem was resolved - an excellent tool!

Posted on Mar 07, 2004 at 20:45:12. [Comments for Venkman Debugger To The Rescue- 1]

Next 5 Results, Previous 5 Results

Breadcrumbs Trail

[ Home ] -> TW Blog -> Firefox and Co
Site Map

The Severn Solutions website achieves the following standards:

[ XHTML 1.0 ] [ CSS 2 ] [ WAI AA ] [ Bobby AA ]

Page compiled in 0.015 seconds