The floater component was built using a combination of JavaScript and PHP. It is deployed by including a certain tag in the XHTML of the tracked system. A detailed description of the deployment can be read in chapter 6. Screen captures of the final interface are shown in APPENDIX B.

PHP is used to create a JavaScript file according to the referrer URL (RURL) given by the browser. The exchange of data is shown in Figure 15.

Figure 15 - The basic flow of data between the floater client and the server

The referrer URL is the URL of the page containing the reference (the script tag) to the PHP file. The database has a base URL (BURL) field for each project. The BURL is a unique identifier and is used by PHP to identify the project. The RURL is compared to the BURLs in the database. If a match is found the appropriate floater code is returned, otherwise floater code with an error report is returned. The process is illustrated in Figure 16.

Figure 16 – Floater process flow

Once the floater code is returned to the browser, it combines it with the content of the page. JavaScript is able to dynamically write to the XHTML source of the document. This written data acts as if it was written normally (the result of Examples 6 and 7 are identical to the user). The combination of PHP processing with JavaScript allows the floater to retrieve and display data from the database regardless of the platform of the tracked system.

script language=”JavaScript” document.write(‘p>Hello world!/p>’); script

Example 6 – JavaScript document writing

p>Hello world!/p

Example 7 – Basic HTML tagging

The floater JavaScript creates a floating layer on the document. This is achieved by placing the floater content inside a div-element. This element is assigned with a position property with the value absolute. Absolute positioning allows the placing of the div- element anywhere in the browser view port. The positioning is set by defining how many pixels from the top left corner of the view port the element should be located.

The files used by the floater are placed in a directory (public/) under the Marmalade root directory. This directory should be publicly accessible. The file structure is shown in APPENDIX F.

Setting the visual properties of the floater

The formatting of the floater is done using Cascading Style Sheets, a technology for specifying the visual properties of elements in XHTML. Today it is the standard way to set properties such as font size, font face and color in XHTML documents. A document can have references to multiple CSS files. An example of the importing tag is shown in Example 8.

style type="text/css" media="screen"> @import "styles/screen.css"; /style>

Example 8 – XHTML tag to import an external CSS-file

In its simplest form CSS styles are set by tag, for example the td tag (table data). Example 9 demonstrates the syntax for setting a property to an element.

td { background-color:green; }

Example 9 – Basic CSS definition for setting table data background color

This definition sets all table data elements to have a green background, unless otherwise specified. The layout of the floater should not be affected by the CSS file of the tracked system so the visual properties should be explicitly described. This is done by using CSS class selectors and naming them correctly (as something that would unlikely be used).

td.marCell { color:#212121; background-color:white; text-decoration:none; font-size:11px; font-family:arial, sans-serif; }

Example 10 – Table data element class in CSS

Example 10 shows the CSS definition for the floater table data element. This definition specifies the background color of the tag explicitly. If the class selector is used (shown in Example 11) the td definition shown in Example 9 would have no effect on the cell even if both styles were imported to the document.

td class=”marCell”>Table data here!/td>

Example 11 – Assigning a class to a table data element

Storing the user path

The floater maintains a history of the path the user has taken. This is done by storing a cookie on the user’s computer. Searchsecurity.com defines cookies as follows: “A cookie is information that a Web site puts on your hard disk so that it can remember something about you at a later time. (More technically, it is information for future use that is stored by the server on the client side of a client/server communication.)” [14]. The process of using cookies is handled by the browser and is transparent to the user.

Arrays in programming languages could be considered as an advanced form of variable. They are used to store a group of related data that can be accessed using different methods (ID numbers, for example). The floater keeps track of the five latest URLs the user has visited in the tracked system. These URLs are stored into an array with a dimension of 1 by 5 (an example shown in Table 4). This array is then stored and updated to the cookie as needed. It would also be possible to use five different cookies, one for each history data. The management of five different cookies would be more complex than managing one cookie with an array.

Cookies are, by nature, simple and hold the following data encoded in a single string:

• Cookie data
• Expiry date
• Allowed domain
• Allowed path

Storing an array into a cookie is not a standard function provided by JavaScript. Stephen Chapman’s Cookie Toolbox is a JavaScript library that has functions for storing arrays into cookies. This is achieved by parsing the array into a single string when it is saved to a cookie and parsing it back to an array when one is read. The library also has other functions that allow effortless cookie management.

Example 12 shows the JavaScript function used to update the user path cookie. PHP is used to assign each cookie a unique name so the user can work on multiple floater- enabled projects without the history cookies intervening with one another. The Cookie Toolbox does not have advanced array-handling functions, so some additional functionality had to be added. In addition, the function prevents the history being filled with a single URL when the page is refreshed by comparing the latest history URL to the current one.

function userPathUpdate(){ var cookieName = 'userPathCookie<?php echo $projectId ?>'; var userPath = init_array(); get_array(cookieName, userPath); var userPath5 = userPath[5]; if(userPath5 == window.location){ // do nothing } else { var pos = 1; del_entry(cookieName, userPath, pos, expires) get_array(cookieName, userPath); var num = next_entry(userPath); userPath[num] = window.location; set_array(cookieName, userPath, expires); } }

Example 12 – The JavaScript function used to update the user path cookie

Bug submission

Once the user has filled in the reporting form and clicked the submit button the system checks that the required fields are filled. The form has three mandatory fields: Description Name * E-mail

If one or more of these fields are missing, the operation is aborted and the user is prompted with a JavaScript alert box. If all fields are valid, the process is taken forward. The data is sent to a PHP script as HTTP post data. A complete list of the fields sent is shown in Table 5. The script handling the submitted data simply saves it to the appropriate fields in the database and prints a confirmation report to the user.

Table 5 - HTTP post data sent by the floater

Browser compatibility

The floater was tested to work on the latest versions of the four popular browsers: Microsoft Internet Explorer, Mozilla Firebird, Opera and Safari. In addition, many browsers today use a common rendering engine and thus the number of compatible browsers is higher. The latest generation Netscape browsers and Mozilla, for example, both utilize the Gecko rendering engine.

In their default configurations all of the browsers mentioned above have both JavaScript and Cookies enabled. If the user disables either one of these the floater will cease to function. Support for old browser versions such as Netscape 4.x.x was not required because development teams tend to use up-to-date browser versions.

Setup of floater using the administration interface

The administration interface can be used to set some properties of the floater. Each project has its distinctive set of values. The available properties are listed in Table 6.

Table 6 - Administration interface options for the floater

Encountered problems

The most serious difficulty was the unreliability of receiving the referrer data from the visiting browsers. The problem arises if the user installs firewall software that alters the browsers functionality so that it no longer sends the data. Some versions of Norton Firewall enable this type of behavior. Secure Hyper Text Transfer Protocol (SHTTP) connections also prevent the sending of referrer data to insecure sites (in this case the server running the Marmalade system).

The solution for this problem is to create custom floater units with hard coded project ID numbers. This removes the dependency for the referrer data. It adds complexity to updating the floater, since altering a single file no longer affects all projects.

Getting the floater to work flawlessly on several projects at the same time was also somewhat of a challenge. Due to the browsers’ caching feature the JavaScript file used to display the floater was not refreshed if the user switched from one project to another. This resulted in corrupted data as project IDs and URLs were incorrect.

The solution for the browser-caching problem was to add random parameters to the URL of the floater. The URLs “http://silvia.local/marmalade/public/index.php?cat” and “http://silvia.local/marmalade/public/index.php?dog” both point to the same file. The cat and dog parameters are not used by the script, but the browser now considers them unique.