Distribution: COMPANY CONFIDENTIAL
Project: Web Browser
Document Ref: 2103,702
Author(s): Steve Cormie, Owen Love, Simon Middleton
Issue: 0.23
Date: 13-Nov-96
Last Issue: 0.22
0.01 SMC 27-Feb-96 First created.
0.02 SMC 05-Mar-96 Added function key mapping.
0.03 SMC 06-Mar-96 Minor changes.
0.04 SMC 11-Mar-96 New UI, filled out more.
0.05 SMC 18-Mar-96 Input from Simon Middleton.
0.06 SMC 19-Mar-96 Modified Java section.
0.07 SMC 21-Mar-96 Added support for SSL and history list.
0.08 SMC 25-Mar-96 Added picture of button bar + more futures.
0.09 SMC 26-Mar-96 Drop back to SSL v2, with v3 in futures.
0.10 SMC 02-Apr-96 Updated for new UI.
0.11 SMC 12-Apr-96 Clarified position on Java/JavaScript.
0.12 SMC 01-May-96 Java/ShockWave moved to futures.
0.13 OL 15-May-96 Modifications to UI.
0.14 OL 07-Jun-96 Updated button bar.
0.15 OL 14-Jun-96 Remove copy image to clipboard.
0.16 OL 24-Jun-96 Updated button bar graphic.
0.17 SJM 03-Jul-96 Added Message and scheme info and updated
various sections.
0.18 OL 04-Jul-96 Updated UI.
0.19 OL 09-Jul-96 Feedback from MGB.
0.20 OL 29-Jul-96 Updated UI.
0.21 SJM 31-Jul-96 Added DrawFile support to future enhancements.
0.22 SJM 22-Oct-96 Brought into line with actual state of browser.
0.23 OL 13-Nov-96 Brought into line with released browser.
There are no outstanding issues.
This document contains the software functional specification for the Web browser included in the system ROM of the Network Computer Model 1. Italicised text is used where issues are still to be decided or where contents are liable to change.
The Web browser to be used for the NC Model 1 is based on STBWeb, a browser originally created for use with Online Media set-top boxes, which was derived from the Fresco browser written by ANT Ltd. This browser was chosen because it was already being modified for use with domestic television sets and to be easily controlled using an IR handset.
The Web browser is modified so that it always runs full screen on both television displays and monitors and complies with the NC Application Requirements Specification. When using a television display the browser uses the NHTwitter module to "anti-twitter" the display.
The NC Fresco can be driven with a mouse, a keyboard or an IR handset. When a keyboard is being used, the following key mappings are applied:
F1 - Display help page
F2 - Display the pop-up menu
F3 - Display Open URL/Favourites List page
F4 - Back to previous page
F5 - Forward to next page
F6 - Show history list
F12 - Toggle button bar
Esc - Stop fetching
Ctrl P - Print
Ctrl F - Find
Cursor up - Select previous link, scroll, or swap frame
Cursor down - Select next link, scroll, or swap frame
Cursor left - Scroll left
Cursor right - Scroll right
Ctrl up - Scroll to top of page
Ctrl down - Scroll to bottom of page
Ctrl left - Scroll to far left of page
Ctrl right - Scroll to far right of page
Shift Ctrl up - Scroll up by a line
Shift Ctrl down - Scroll down by a line
Shift Ctrl left - Scroll left
Shift Ctrl right- Scroll right
Page up - Scroll up by a page
Page down - Scroll down by a page
Ctrl Tab - Move highlight to next frame
Shift Ctrl Tab - Move highlight to previous frame
Enter - Confirm options
When a IR handset is being used, (also read the NC IR Software Functional Specification) the following function key mappings are applied:
Help - Display help page
Menu - Display the pop-up menu
Select - Confirm options
Line up - Scroll up by a line
Line down - Scroll down by a line
Page up - Scroll up by a page
Page down - Scroll down by a page
Arrow keys - Move the highlight
Back - Back to previous page
Forward - Forward to next page
Home - Return to home page
Stop - Stop fetching
Open - Display Open URL/Favorites list page
Mouse users are able to scroll the page in all directions by clicking the mouse button on a web page and dragging the mouse pointer in the direction they wish to scroll. If the region clicked is activatable (eg a link) then the page will be dragged if the mouse pointer is moved a minimum distance within a specified time limit, otherwise the link will be followed.
A button bar will be displayed along the top of the screen display. This bar can be toggled on/off using a menu item or the function key F12. The button bar takes the form of a window with no borders which covers a small area at the top of the display. It is ensured that all components on this button bar fall within the safe areas for PAL and NTSC televisions. The button bar is anti-twittered if necessary and contains the following components:
Menu - Display the pop-up menu
History List - Display the history list
Add to Favorites * - Add current page to favorites
Print * - Print page
Back - Back to previous page
Forward - Forward to next page
Home - Return to home page
Stop - Stop fetching page
Refresh - Refresh the contents of the current page
URL - Display Open URL/Favourties List page
Find * - Find text
Help - Display help page
Page Up/Down - scroll up/down by a page
Page Left/Right - scroll left/right by a page
NC Logo - spins when transferring data
Status line - Showing page title, status info and help
Connection lights - the state of the current connection.
Two different button bars are supported; one for monitor displays and one for television displays. The TV graphics are larger and therefore less buttons can be displayed. The button bar options noted with * are not displayed if you are using a television display.
The button bar for NC Fresco displayed on a monitor looks like this:
The button bar displayed on a television looks like this:
The status line along the bottom of the button bar will normally display the title of the current page. However, when the user moves the pointer over the icons on the button bar (or items on the menu tree) this icon should be used to give users additional information about the selected icon/item. This status line is also used to display downloading information when the browser is fetching pages.
The three connection lights beneath the spinning NC logo are used to indicate what state the browser is in as it attempts to connect with the requested URL. The first light means the browser is attempting connection. The second is the browser is connecting to the destination. The third and final light is when data transfer is completed.
A pop menu will be available giving a complete list of operations that can be peformed. Mouse users will press the menu button on the button bar to invoke the menu whilst keyboard users will have to use F2 and IR handset users, the menu button on their controller. The first menu item will be highlighted, by using either the cursor keys or the mouse pointer, users will be able to navigate the list and confirm their choice by pressing Enter or clicking the mouse button. Pressing Escape, F2, or the menu button will remove the menu. The menu will list the following options:
| Main | Page , Navigate , Favorites , Find , View |
| Page | Print , Print options , Stop fetching , Refresh page |
| Navigate | Open URL , Home page , Back , Forward , History list |
| Favorites | Favorites list , Add page , Remove page |
| Find | Find text , Find text again |
| View | Backgrounds , Images |
The NC Fresco is modified over and above the original STBWeb specification to handle the following additional functionality:
A mechanism is introduced to allow HTML pages to send commands to the browser. This is done through the pseudo-scheme ncfrescointernal:.
When the browser tries to follow a URL of the form ncfrescointernal:<action>?<options> then the behaviour is as follows.
| Action | Arguments | Behaviour |
|---|---|---|
| back | Go back to previous page | |
| home | Go to home page | |
| hotlist | Show hotlist | |
| history | Open history list | |
| loadurl | url | Open the URL passed |
| playmovie | url | Play the replay file given |
| args | Extra args to pass on command line to replay | |
| cancel | Close a dialogue box type page |
The favorites list is implemented as an HTML page which is created from a text file containing pairs of page URLs and titles. It is loaded from and saved to the location indicated by the system variable NCFresco$Hotlist. This normally points to a file in the user's home directory. Pages can be added and removed from the favorites list. This page also contains a writeable icon which allow users to type in a URL directly.
The history list is implemented as an HTML page which is created and displayed when the user clicks on the history list button on the button bar or chooses the 'Show page history' menu option. The generated HTML page (but not the internal history list) is discarded when the user selects a link and does not itself form part of a future history list.
A mechanism whereby Replay movies can be embedded and played in HTML pages is introduced. When the browser sees the HREF ncfrescointernal: it knows that what follows is an instruction to the browser rather than a real URL. For example, the following HTML embeds an initial image for and plays back a Replay movie when the image is clicked on.
<A HREF="ncfrescointernal:playmovie?url=[URL OF MOVIE]">
<IMG SRC="[INITIAL IMAGE]">
</A>
Where [URL OF MOVIE] points to the Replay movie
eg. file:/Replay:Shuttle2 for a movie on the local file
system and using the path Replay:. Also, [INITIAL
IMAGE] is the file name of the image to display before and
after playing the movie. Obviously, it is possible to specify other
image options for centering etc.
The Web browser uses a MIME mapping to assign RISC OS file types to files which are downloaded from the Web. If the browser does not know what to do with a particular type (there are only a small number which it knows about) and appropriate system variables have been set up then it will run the file. This will start up an application which then handles the file.
A helper application !SoundPlay has been written to play sound files in this fashion. It supplies no user interface, multitasks and supports playback of WAV, AIFF, AU, PSION, VOC, and Amiga 8SVX sound formats.
Applications can be launched by setting up a pseudo-scheme similar to the ncfrescointernal: scheme described earlier. These URLs can then be used from simple links or from forms. In all cases the scheme name is used to determine what command to run but the full URL is always passed to the command.
If an application had set up the following alias
*Set Alias$URLOpen_FOO /<Foo$Dir> -URL %*0
then it could be used in the following ways.
if the user clicks on a link of the form <A
HREF="foo:myaction"> </A> then the command
*/<Foo$Dir> -URL foo:myaction will be run.
If the user clicks submit on a form with a foo: action
and METHOD=GET then the form results will be appended to
the URL passed on the command line. eg
<FORM METHOD=GET ACTION="foo:myaction">
<OPTION NAME=bar CHECKED>
<INPUT NAME=fred VALUE="barney" >
</FORM>
When this form is submitted the command line generated will be
*/<Foo$Dir> -URL foo:myaction?bar&fred=barney
If the form required will contain more data than could be fitted
within the 256 character command line limit then you can use a form
with a foo: action and METHOD=POST. In this
case the form results will be written to a file and the filename
passed on the command line. eg.
<FORM METHOD=POST ACTION="foo:myaction">
<OPTION NAME=bar CHECKED>
<INPUT NAME=fred VALUE="barney" >
</FORM>
When this form is submitted the command line generated will be
*/<Foo$Dir> -URL foo:myaction <temp file>
where <temp file> is a temporary file in the scrap directory. This file
will contain bar&fred=barney exactly as were appended to
the command line in the GET case.
Note that in all cases the data, whether appended to the command line or written to a file will be encoded in the following form.
See the description of message OPEN URL for details on how this is handled in message form. In fact the OPEN URL message is broadcast first and only if it bounces will the URLOpen alias be used.
Note: The earlier mechanism of allowing any command to be prefixed by ncfrescointernal: has been removed for security.
The NC Fresco is used as a front end for the NC but is forced to operate in a different mode where the toolbar and all of the keyboard controls are not available. This means that all navigational functionality must be provided by the HTML pages used for front-end purposes and potentially allows some quite sophisticated front-ends to be built using HTML eg. using client side image maps.
The NC Fresco must therefore work in one two modes as dictated by the current HTML page, browser mode, where the toolbar and function keys are available and desktop mode where they are not. It is assumed that each new page starts off in browser mode ie. the toolbar will be displayed, unless the page contains the following extension of the META tag:
<META NAME="browsermode" CONTENTS="desktop">
Not all keyboard controls are disabled when in desktop mode. The page/link movement and select keys can be used in both modes.
The NC Fresco supports the RISC OS global clipboard as specified in the Support Group Note 240 - "The RISC OS Selection Model and Clipboard". The browser allows images to be selected and copied to the clipboard through menu selections only. A menu item is also provided to copy the whole text to the clipboard.
Frames are a method of displaying multiple HTML files on screen in a controlled fashion. Each document can be independently scrolled and the space for each document may be reallocated by the user.
The browser uses the standard WIMP furniture for scroll bars.
The cursor link highlighting algorithm is modified to move the cursor from frame to frame whilst following links. If the highlight reached the bottom of a frame it will move to the top of the next frame and similarly when moving backwards.
Reference: http://www.netscape.com/assist/net_sites/frames.html
Tables are implemented according to the latest available W3C draft specification (currently 23-Jan-96). This draft contains methods to allow correct rendering of tables written to display on existing browsers.
Reference: http://www.w3.org/pub/WWW/TR/WD-tables
Client-side image maps are supported according to the internet draft document referenced. Selecting an image map attempts to use a local description, degrading to use of a server side imagemap if necessary (and available) without user knowledge. Status information on the URL referenced by the area under the pointer is displayed in the status bar.
Reference: http://ds.internic.net/internet-drafts/draft-seidman-clientsideimagemap-02.txt
Cookies are pieces of information that link a site or portion of a site with a user. They need to be stored when received, possibly kept across sessions, and sent back to the server when the approriate URLs are accessed.
Cookies are stored in a file referenced by the environment variable NCFresco$Cookies, typically in the users home directory. This file is updated whenever a new cookie is received or one expires. The limits on how many cookies should be held at one time are defined in the spec referenced. This is checked when a new cookie is added and cookies are expired on a least recently used basis.
Reference: http://www.netscape.com/newsref/std/cookie_spec.html
The Web browser uses the following system variables to obtain welcome, home and help pages:
<NCFresco$Welcome>
<NCFresco$Home>
<NCFresco$Help>
This allows these pages to be customised and loaded from anywhere on the network rather than being in fixed places. The welcome page will typically be a control page which contains a selection of services or applications and is where the NC Fresco returns when the close button is clicked on the toolbar (ie. back to the "desktop" mode root page). It also allows for a separate home page which is where the browser returns to when the user selects the Home option in browser mode.
These system variables are not cached by the browser so they can be changed during the session eg. for context sensitive help.
The NC Fresco is improved to provide better printing support such that lines of text or images are no longer cut off at the bottom of the page and then repeated on the next page.
The NC Fresco is extended to support floating images ie. where text wraps at the side of images rather than the images forming a component of a single line of text.
The parser in the original browser was derived from free code from the W3 consortium and has already proved to be not very robust in the face of incorrect HTML. This is particularly true in the case of comments, which are very commonly used wrongly.
For these reasons a new parser is included as part of this browser replacing the W3 code and interfacing to the existing ANT code.
The development of a new parser also has the benefit of allowing future support for JavaScript which is usually included in HTML comments and was originally always discarded.
The following new features from the draft HTML 3.2 document published by the W3 consortium during development are now implemented.
The FONT COLOR and FONT FACE features also likely to be included in HTML 3.2 are not implemented.
The following message is supported to allow the browser to broadcast a request for another application to handle an unknown URL type or for another application application to ask the browser to render a page. This message is derived and extended from an existing mechanism in ANT Fresco.
union
{
char *ptr;
int offset;
} string_value;
struct
{
wimp_msghdr hdr;
union
{
char url[236];
struct
{
int tag;
string_value url;
int flags;
string_value body_file;
string_value target;
} indirect;
} data;
} event_data;
If the string representing the URL that needs to be opened is less than 236 bytes long and no body file or window target needs to be specified then it may be sent in the array of bytes event_data.data.url.
Otherwise the indirect form must be used. The tag value event_data.data.indirect.tag should be set to zero. Each of the 'string_value' fields above can then take one of three values.
The flags are currently all reserved and should be set to zero.
The WIMP message wimp_MOPENURL, number 0x4AF80, should be broadcast with the above data, with an event code of wimp_ESENDWANTACK.
When an application receives the about WIMP message it should first determine where the URL is stored by testing the length of the string in event_data.data.url. If this is non-zero it should use the immediate string otherwise it should use the indirected strings. The application should examine the string and determine whether it can service the request. If it can service the request it should acknowledge the WIMP message before it next polls the WIMP manager. If it can not service the request it should simply ignore the message.
In the indirected case the application should also check the size of the message block to see which fields in the indirect block are valid. Older applications will broadcast the indirect request with only the tag and url fields. In this case the message will be 28 bytes long.
Note that for maximum compatibility with older receiving applications the indirected URL field should always point into the RMA as otherwise an older application will attempt to interpret the 'offset' form as a direct pointer and read from zero page which may cause a data abort.
New applications should allow for the URL being in offset or direct pointer form however for maximum flexibility.
If the requesting application receives a 'bounced' version of the WIMP message it should try to start an application to open the URL. It does so by issuing a Wimp_StartTask SWI with the command 'URLOpen_<scheme> <URL>'. If this raises an error the appliaction should notify the user that the URL could not be followed.
If no 'bounce' is received then the application should assume that the URL has been opened by some other application.
This message may be sent or handled by a number of applications. A WWW browser will send the message when the user tries to follow a link with a method that is not supported internally to the browser. The browser may also respond to the message when the method is 'HTTP'. An email or news application should examin URLs and respond to those that have a method of 'mailto' or 'news' (and maybe 'nntp'). This application may also allow the user to menu over the body of a mail or news item, try to pick out a fragment of text below the pointer that looks like a URL, and broadcast a request made from this. An FTP client should detect requests with a method of 'FTP' and service them accordingly.
Applications should, as well as accepting the WIMP message, provide a startup option that allows a URL to be specified on the command line. They should then set appropriate aliases to start the application when a URL of a known scheme is found. Thus a WWW browser should have in its !Boot file a line such as:
if "<Alias$URLOpen_HTTP>" = "" then
Set Alias$URLOpen_HTTP Run <Obey$Dir> -URL %%*0
The browser recognises a special target name __help.
If it receives an open URL request to this target then it will open
a temporary browser window at the top of the window stack with the
desired help page. When this window is closed (by use of the
ncfrescointernal:cancel link) the caret will be returned
to the window it was in when the request was sent.
A typical URL for some help pages might be file:/NCHelp:NCWriter/index.html
This message is to allow some degree of remote control over NC Fresco.
HTML is a proven mark up language for the delivery of hyperlinked multimedia material across large distributed networks. It has now become the standard delivery mechanism for information across the Internet and has a large base of authoring tools and support.
The Web browser conforms to the HTML 2 specification but has extensions for frames, tables, client side image maps and client side cookies plus other proprietary extensions.
The NC Fresco supports version 2.0 of Netscape's Secure Sockets Layer which is a security protocol that prevents eavesdropping, tampering or message forgery over the Internet. Standards documentation can be found at the following URL.
Reference: http://home.netscape.com/newsref/std/SSL.html
None.
A paper based document called 'Test Definition for NC1 Web Browser' written by High Integrity Systems Limited is available separately.
The browser consists of a small number of support modules plus the main application itself. These are all integrated into the RISC OS build tree so that the browser can be built into the NC ROM.
Java and ShockWave (MacroMedia Director) will be supported by implementing the <OBJECT>, <EMBED> and <APPLET> tags. NCFresco will use nested WIMP windows as described in the Nested Wimp Software Functional Specification and the plug-in message protocol as described in the Plug-Ins Software Functional Specification to call on plug-in applications to render Java and ShockWave "applets".
There is often a confusion between Java which is designed by Sun and JavaScript which has been created by Netscape and is more a mechanism for controlling the browser. The two are similar in syntax but are most definitely not the same thing. There is currently no intention of supporting JavaScript for the first release of product.
SSL (Netscape's Secure Sockets Layer) version 2.0 has a limited lifetime and it is expected that the NC Fresco will need to support SSL version 3.0 by the end of the year.
This is a generic, structured, way to control how an HTML document is rendered on screen or page. It is supported by Microsoft Internet Explorer version 3 and is expected to be included in Netscape Navigator version 4.
Reference: http://www.w3.org/WWW/Style/
This is a ratings system for web sites that is being backed by the major internet players.
Reference: http://www.w3.org/PICS
Two groups, Microsoft, and a consortium of Adobe, Apple and Netscape have separately made proposals on embedding downloadable fonts in HTML documents. Both proposals may involve the use of TrueType fonts.
Reference: http://www.w3.org/WWW/Fonts/
The following list gives some examples of HTML functionality in use by other browser vendors which could be incorporated into the NC Fresco.
It would be useful, for in-house and NC specific use, to be able to include DrawFiles in an HTML page as no vector formats are currently supported. This will be accomplished by use of the OBJECT element, although the support will be built-in rather than via a plugin.