THIS PAGE MAY BE OUTDATED
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page.

Design Overview

Introduction

Graphical Timeline is a new and interesting way of debugging in Firefox. It visually displays the events happening in your browser in real-time that may originate from any number of different data sources. For each source, a Producer watches, extracts and creates data based on the underlying Component. These data are then sent to the Data Sink which retains them for retrieval and display by the Timeline User Interface.

Producers

Each Module or Component we wish to represent in the Timeline will have a Producer attached to it. The implementation of each producer will vary depending on the component it watches, but the data each produces should be of a consistent format. Each producer is tightly associated with the Data Sink but has no link with any other component of the Timeline.

Event Types

Data created by the Producers can be of several types:

• Point Events: Single moment events like mouseup, load, etc.
• Continuous Events: An event spanning a duration of time. Continuous events must be represented by a starting event and an ending event. They can also have intermediate events corresponding to the same continuous event.
• Repeating Events: Multiple events that occur at varying points in time. Could be considered as either multiple Point or Continuous events that are tied together.

Data Sink

The Data Sink is a central repository for the data created by each Producer. Its main purpose is to act as an intermediate component between the producers and the User interface. Data collected from all the producers are transmitted to the User interface using Custom Events (Remote Debugging Protocol, in future). Data Sink has a single format of data that it accepts from any producer.

Normalized Event

Any event to be transmitted to the User interface should follow this normalized event structure. The event should be an Object with the following properties:

• id: A unique id for the event. This is automatically created by the Data Sink to maintain uniqueness.
• groupID: A unique id that is common for the events falling to the same interval (continuous or repeating).
• name: A name related with the event to show up on the User interface.
• nameTooltip: Tooltip for the name to show up on the User interface.
• type: This represents the type of the event being captured. It can be one of NORMALIZED_EVENT_TYPE.
• producer: The id of the producer from where the data originated. This id is provided by the producer itself at the time of registering itself to the Data Sink.
• time: Time of the event occurrence.
• details: This can hold any amount of information related to the event that is to be transmitted. The format is provided by the Producer at the time of registering.

NORMALIZED_EVENTS_TYPE

Any normalized event can be of one of the following type:

const NORMALIZED_EVENT_TYPE = {
  POINT_EVENT: 0,              // An instantaneous event like a mouse click.
  CONTINUOUS_EVENT_START: 1,   // Start of a process like reloading of a page.
  CONTINUOUS_EVENT_MID: 2,     // End of a earlier started process.
  CONTINUOUS_EVENT_END: 3,     // End of a earlier started process.
  REPEATING_EVENT_START: 4,    // Start of a repeating event like a timer.
  REPEATING_EVENT_MID: 5,      // An entity of a repeating event which is neither
                               // start nor end.
  REPEATING_EVENT_STOP: 6,     // End of a repeating event.
};

Timeline User Interface

The User interface for the Timeline is a scrollable, zoomable canvas containing the events with multiple tracks for each producer. Within each track, we will have additional groupings. The data within the timeline is adaptable to the zoom level of the display. As a user zooms into the timeline or expands the view, more data becomes visible.

Flow of Events in Timeline

This section explains the basic flow of events inside the Graphical Timeline.

Producer Registration

Each producer is a separate module which needs to import the Data Sink module and register itself before it can send any event data to the Data Sink. Without registration, the Data Sink will not even start the producer. A producer passes all the important information needed by the Timeline User Interface during this registration process.
For more information read Creating and registering producer

Data Sink Initialization

After all the Producers have registered themselves, the Data Sink must be ready for activation on a signal by the Timeline User Interface. Once the listener is active, the user interface can start the Data Sink and thus all (or some of) the registered producers.

User Interface Setup

As soon as the user opens the timeline user interface, a handshake ping is sent to the Data Sink. Data Sink registers the UI with a unique id and sends back the information of all the registered producers. The user interface thus builds the UI based on this information. User can now enable/disable any producer or its sub-features and send an event to start the recording of events.

Remote Debugging Protocol

Timeline will soon follow RDP to transfer data information between Data Sink and the User Interface.

Current Scenario

Both the Data Sink (and thus the producers) and the Timeline UI are currently a single entity and reside in the same Firefox window due to the limitations of using Custom Events. Therefore, currently the Timeline is a one to one developer tool which can only be used to debug the page being viewed in your browser.

After RDP

After switching to RDP for any kind of transfer, data can be transferred over the network to a remotely located user Interface. This will allow a user to debug a page that is opened on his mobile Firefox from the desktop Firefox. Extending the RDP, we will also achieve the ability to connect more than one User Interface with a single Data Sink, so that more than one desktop Firefox can debug a page from a single mobile Firefox.