Skip to content

Instantly share code, notes, and snippets.

@mihaisucan

mihaisucan/webconsole-output-rewrite.md

Last active December 16, 2015 07:29
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save mihaisucan/5399023 to your computer and use it in GitHub Desktop.
Save mihaisucan/5399023 to your computer and use it in GitHub Desktop.
Download ZIP
Planning for the Firefox Web Console output rewrite/reimplementation. See bug 778766.
Raw
webconsole-output-rewrite.md

Web Console output rewrite plan

This document describes the work we did for the Web Console output rewrite / reimplementation, see bug 778766.

Implementation is mostly complete. We still need to fix up message filtering and grouping.

This document does not accurately reflect the current Web Console output API. See the MDN page about the console output API.

Current issues

Issues currently affecting the Web Console output:

  • page navigation/reload issues:
    • add an option to clear messages on reload, bug 705921.
    • add a marker for each reload, bug 793996.
    • group / gray out / mark as obsolete output from previous reloads, bug 655700.
  • customized output for different types of objects:
  • you cannot select freely any text in the output:
  • add stack traces to every console API call, bug 920116, and every script error, bug 814497.
  • accessibility: make clickable output keyboard accessible, bug 588010.
  • too much output:
    • remove timestamps from Web Console, bug 909750.
    • turn off CSS warnings by default in Web Console, bug 909756.
    • remove NET filter button, logs from Web Console, bug 909754.
    • improve filtering:
      • provide APIs for filtering existing and new messages added to output, bug 837774. current filtering logic is based on xpath and walking DOM nodes...
      • highlight category button when a new message is added, if the category is off - bug 801067.
    • grouping:
      • allow grouping of messages based on custom logic.
      • allow custom logic for grouping repeated messages.
      • allow expansion of grouped repeated messages, bug 704252.
      • timestamps should be expandable/collapsible, bug 722267.
  • performance issues:
    • layout is flushed by reading scrollHeight too often, bug 746870.
    • HS_regroupOutput() is too slow and irrelevant as it stands, bug 746871.
    • pruneOutputIfNecessary is too slow, bug 746872.
  • lack of polish and UX issues:
    • messages are not interleaved correctly based on their times, bug 755555.
    • links can open using any mouse button, bug 653710.
    • links in errors/warnings cannot be clicked/copied, bug 663370.
    • clicking in blank areas of messages opens popups/sidebar, bug 773291.
    • better UX for all links in output, bug 776939.
    • integrate the JSTerm input line with the Console Output area, bug 865708.
    • No value to execute" has no value, bug 835951.
    • text copied from the Console does not include the "[Mixed Content]" substring, bug 874591.
    • add tooltip to the repeat bubble, bug 675487.
    • the choice of fonts need to be checked again, bug 674422.
    • remove underline for network request links, bug 696385.
    • display column number in addition to line numbers, bug 684096.
    • incorrect URL shown when a hash is used, bug 724224.
    • add option to reverse messages order, bug 864934.
  • window.console API improvements and new features that depend on a more flexible output implementation:

This list is somewhat sorted by priority. Do note that visual and keyboard accessibility, along with performance, are overall goals that should be under our constant attention.

Suggestions to prioritize bugs are welcome.

The codebase we have makes it hard to experiment with output changes - there's a lot of arcane logic and hacks. It is also hard to add new (custom) messages using the Web Console API, see bug 775607. There is also technical debt, cleanups we need to do:

  • move methods from the HUD Service to the individual HeadsUpDisplay objects, bug 592523.
  • use attributes instead of classes for category/severity, bug 628019.
  • cleanup confusion over console node, hud box and output node, bug 643135.

Goals

Overall goals in no particular order:

  • improve user experience by polishing the output. We have a lot of bugs about simple issues that can be fixed to improve UX.
  • improve the output visual appearance.
  • make it easier to manage a lot of output by improving filtering, search, message grouping and more.
  • make it easier for Mozilla developers to iterate on output changes, to add new kinds of messages, and to write new tests.
  • add specialized output for different kinds of objects, to improve the overall console usability.
  • make it easier for us to add APIs for addons to customize the output for different types of objects and to add custom message filtering logic.
  • improve accessibility.
  • improve performance.

To achieve these goals we will:

  • rewrite the way the Web Console output works - APIs, DOM output and styling.
    • this will happen gradually in several bugs, as explained in the Implementation plan section below.
  • we will switch from XUL to HTML for output to make it easier to have custom messages, from any of the API users.
  • move code related to output into a separate reusable component (see ConsoleOutput), in order to simplify the Web Console and to allow extensions to reuse the output features outside of the console.

We have considered using the Source Editor component for output, however we believe that the editor is tailored for use cases that are too different to those of the Web Console. Using the editor as a base layer has a greater potential of imposing unwanted limitations, long term.

The new Web Console output API

The HUDService.jsm file will continue to be the Firefox and toolbox glue for the Web Console user interface. This file should continue to be kept as lightweight as possible.

All output will be HTML to make it easier to integrate other pieces of output that come from outside of the Web Console.

Changes in the webconsole.js file

The webconsole.js and webconsole.xul files will continue to hold the user interface implementation for the Web and Browser Consoles. I would like the XUL file to continue to hold the basic console UI as opposed to having to create each DOM element from JavaScript during initialization.

For webconsole.js I would like to see it become much lighter. It is currently bloated and it includes a lot of the older Web Console's arcane legacy code.

The WebConsoleFrame and JSTerm objects will continue to exist, while almost everything related to output will move into ConsoleOutput.jsm.

The JSTerm input and autocomplete code will be refactored later, after the output work. That will be a simpler and quicker endeavour.

Do we want to write down a plan here for JSTerm input and autocomplete as well?

We will add an output property to the WebConsoleFrame object which will hold an instance of ConsoleOutput.

Filters and message taxonomy

We will keep setFilterState() and getFilterState(): the Web Console UI will continue to manage filter UI (the buttons) and state. We currently have a rather confusing mix of things: categories, severities, log levels and class names.

I propose that we do not impose any strict set of filter categories, severities, etc. I think we should have each button associated to a flag name / pref key that is either on or off. Messages will have their own filter logic which can check for any of these flags. This should allow us flexibility in terms of UI: we can later change those filter buttons and menus as we want as long as we set the right filter flags. We can add/remove flags freely - it's up to the messages we implement if they react to them or not.

When the filters state change via API calls or due to UI interaction we will invoke ConsoleOutput.onFilterStateChanged() or ConsoleOutput.onFilterTextChanged(). Then it is all up to the ConsoleOutput to do the message filtering.

Instead of calling the onFilterStateChanged()/onFilterTextChanged() methods on ConsoleOutput we could emit events. Should we do that? ConsoleOutput could listen to these events on the owning WebConsole instance and react to such changes.

The flags-based approach should allow us to have the same message belonging to multiple "categories" and any severity. We can also output messages that do not belong to any category or severity, as in the case of JavaScript evaluation input and output.

Log limits: currently we have log limits per categories and we prune messages per category. We also have undocumented preferences allowing users to change the log limit for each category. In my opinion this is over the top, and we should simplify to a single log limit that limits the number of messages we display, overall. This would help us simplify output queues and pruning. We can also have one documented preference for this log limit.

Message sorting

Currently messages are not sorted by the Web Console based on their timestamp. They are shown as they arrive, in order. The timestamp is not taken into consideration. For JavaScript evaluation results we force the output to always be next to the user's input.

We have previously discussed the possibility of enforcing sorting. Do we want this? I doubt we want it as it makes things potentially a lot more complicated for little benefit.

Based on bug 755555 we need to insert messages in their correct location based on their timestamp.

Related to sorting, I would like us to introduce the option of reverse order for messages, like the Error Console can show first > last or last > first. See bug 864934.

To avoid hacky ways of enforcing JavaScript evaluation results to immediately follow user's input we will use the new grouping concept in ConsoleOutput.

Copy to clipboard

We currently use xul:richlistitems to render messages in the Web Console output. This allows users to select the whole message with a single click, like any list item.

Copy to clipboard is currently implemented by reading the list of selected message items. Each message element has a text-only representation, a clipoardText property. We manually take the clipboardText value from each selected message and join these together, then we put these in the clipboard.

The current approach is ideal for the purpose at hand - we can always make sure that the text we copy to clipboard is properly formatted. However, once we fix bug 706755 we will allow free text selection. We will switch to HTML div elements, which means copy to clipboard will work as it does in any web page. That will provide users with less than ideal text formatting in their clipboard.

At a later point we might want to re-evaluate this decision. We can always add a clipboardText property to message objects.

New module: ConsoleOutput.jsm

The new ConsoleOutput.jsm would export a reusable component for building something like the Web Console output. This file will contain the following objects:

  • ConsoleOutput

    Output manager: how to add new messages, how output is queued, pruning, filtering, removal of messages and scrolling.

  • Messages.BaseMessage

    Base object from which all of the other message types inherit. This will include minimal API to get a usable message.

  • Messages.Simple

    This is going to be the simplest type of message you can use to output something to the console: it will support HTML content, a message source link, basic filtering, repeating, along with the option of assigning the message a category and a severity. To display the message source we will use the MessageSource widget. The MessageTimestamp widget will be used to display the timestamp.

  • Messages.JavaScriptEvalInput

    Will be used for displaying JavaScript input that is evaluated. The JavaScriptSnippet widget will be used to syntax highlight user's input.

  • Messages.JavaScriptEvalOutput

    Will be used for displaying JavaScript input that is evaluated. Initial implementation will use the JSObject widget to make the result available for inspection. For DOM elements we will use Widgets.DOMElement.

  • Messages.NetworkRequest

  • Messages.NavigationMarker

    Will be used for bug 793996.

  • Messages.ConsoleGeneric

    Will be used for almost all of the window.console API messages. JavaScript objects and DOM elements will be rendered with the appropriate widgets (JSObject and DOMElement).

  • Messages.ConsoleDir

    This is for console.dir() messages. The VariablesView widget will be used for displaying an inline VariablesView instance.

  • Messages.ConsoleTrace

    This is for console.trace() messages. The Stacktrace widget will be used here, with nicer UI than now, to fix bug 790309.

  • Messages.ConsoleGroup used for console.group() messages. This object extends BaseGroup.

  • Messages.ScriptError

  • Messages.StyleError

  • Messages.BaseGroup inherits the BaseMessage object and it is used as the base for all types of groups. See the BaseGroup API section for details.

  • Widgets.BaseWidget

    Every widget inherits from this one.

  • Widgets.MessageSource used for displaying the message source for most types of messages.

  • Widgets.MessageTimestamp used to display the message timestamp.

  • Widgets.JavaScriptSnippet

  • Widgets.CSSSnippet

    Reusable widgets for displaying JavaScript and CSS with syntax highlighting. We can probably reuse parts from CodeMirror when that lands.

  • Widgets.Stacktrace will be used for displaying stacktraces for console.trace(). Once we fix bug 814497 we will also use it for window.console API messages and for script errors.

  • Widgets.JSObject

    Widget that displays an ObjectActor and allows users to inspect the object using the VariablesView in a sidebar.

  • Widgets.DOMElement

    Similar to the JSObject widget but for DOM elements. The object will be rendered as an HTML tag: <tag id="foo" class="class names">. This will fix bug 682033.

  • Widgets.VariablesView

    Reusable widget for messages that need to display an inline VariablesView.

  • Utils

    Holds common static methods we need throughout the code.

Each message object is meant to handle its own state - render itself, filter, destroy, etc. The current Web Console output implementation is far too cumbersome in this regard: we have one big createMessageNode() function that renders all kinds of messages. There's a similar situation with message filtering, repeated message detection, pruning and removal.

Widgets are meant to be reusable bits of UI within message objects. For example the JSObject widget is reusable for all of the console messages that need to display an inline object (an ObjectActor) that you can inspect in the sidebar with VariablesView.

Groups are message objects that also act as containers for other messages. We will use these for rendering groups of different kinds as explained in the section about the BaseGroup API.

The variables view sidebar will continue to be part of the Web Console API, outside of ConsoleOutput.

The ConsoleOutput object

The ConsoleOutput manages the output messages: how to add new messages, how output is queued, pruning, filtering, removal of messages and scrolling.

Proposed API:

  • constructor(owner, parentElement)

    • owner points to the owning Web Console instance.
    • parentElement points to the output element in the iframe where messages will be added.

  • addMessage(message...) allows you to add multiple messages at once. Each message is added to the output queue (async render).

  • removeMessage(message...) allows the removal of messages.

  • onFilterTextChanged(newText)

  • onFilterStateChanged(filters)

    Async methods that are invoked when any of the filters change. The filters object holds the state of all known filters. This method goes through all message objects and calls onFilterStateChanged() for them. Once this operation completes the messages-filtered event fires.

  • findGroupForMessage(message) comes from Messages.BaseGroup. See that for details.

  • findRepeatedMessage(message) returns a message object that is equivalent to the given message.

  • destroy()

Properties:

  • element points to the DOM element container for all of the messages.
  • groups is an array that holds groups.
  • messages is an array that holds all known message objects.
  • document is a reference to the DOM document that owns the output.
  • window is a reference to the DOM window that shows the messages.

Available events:

  • messages-added fires whenever messages are added to output, after the fact. The event object includes a set with the new messages.
  • messages-updated fires after the output is updated, for messages that change their content due to user interaction. The set of updated messages is included.
  • messages-removed fires when messages are pruned or otherwise removed.
  • messages-filtered fires after messages are filtered. The event object includes messages that match.
  • groups-opened fires after one or more groups are opened. The event object includes the set of groups that changed state.
  • groups-closed fires after one or more groups are closed. The event object includes the set of groups that changed state.

The first three events are already partially implemented in WebConsoleFrame.

The BaseMessage API

Each message object needs to:

  • generate its own unique ID used to determine if two message objects are equivalent;
  • render itself when ConsoleOutput asks it to;
  • update itself when a duplicate message is found in the output queue;
  • filter itself based on user's text input or based on custom flags;
  • show/hide itself when needed (for example due to filtering);
  • destroy itself when the message is removed.

The BaseMessage class is not meant to be used on its own. It has almost no logic, it cannot render itself, it has no timestamp awareness, non-working filtering capabilities, etc. All message types extend from this class or subclasses.

Methods:

  • constructor(....) each type of message has its own constructor that takes whatever it needs. For example window.console API related messages will take the console message received from the server, which includes the arguments and the rest of API call information.

    Once constructed messages don't do almost anything and they are unowned.

  • init(output, parent) is invoked by the ConsoleOutput instance once you do output.addMessage(message). The parent will be the parent message if there's any (this is given only if this is a child message in a group). This is when the message becomes owned by a ConsoleOutput.

  • onDuplicateAdded(duplicateMessage) is invoked by the ConsoleOutput instance during output flush if it finds a repeated message. This method takes that new repeated/duplicate message and updates this message instance. For example, you can update the repeats counter and keep track of time stamps of duplicate messages.

  • onRemoveFromQueue() is invoked only by ConsoleOutput if this message object will be pruned from the output queue before it is rendered.

  • render() is invoked when this message is displayed. It updates the message.element property to hold the DOM element that is added into the document by the parent message or by ConsoleOutput. Calling render() multiple times gives you the same element.

  • onRemove() is invoked once this message is pruned or otherwise removed after it was once rendered.

  • onFilterTextChanged(newText)

  • onFilterStateChanged(filters)

    Invoked when any of the filters change. The filters object holds the state of all known filters. This method returns a boolean that tells if this message should be hidden or not.

Properties:

  • output points to the owning ConsoleOutput instance.
  • parent gives the parent group of the message (if any).
  • element gives the DOM element of this message, if it was ever rendered.
  • visible boolean that tells if this message is visible or not. This is also a setter that allows one to hide/show the message. This is used for filtering.
  • textContent string that gives the full message content.
  • repeatID string that can be used to track if older messages are equivalent to this one. By default BaseMessage always provides a unique ID - no message is ever considered a repeat.
  • widgets set of widgets contained by this message.

We might need:

  • scrollToSelfOnAdd boolean property that tells if ConsoleOutput should scroll to this message once it is rendered. This is useful for important messages like JavaScript eval input/output.

    > Would this be a bad approach?

The Messages.Simple API

The Simple message extends the BaseMessage API making it usable for basic message output. This is the base class for most of the messages in the Web Console. The BaseMessage class should be used as a base only if you need a message type that has more advanced requirements related to rendering and filtering.

Methods:

  • constructor(message, options = {}) where message is the message you want to display. Options:
    • html - (boolean) tells if message is HTML or not. Defaults to false.
    • category - (string) category that this message belongs to. Defaults to no category.
    • severity - (string) severity of the message. Defaults to no severity.
    • timestamp - (number) date and time when the message was recorded. Defaults to Date.now().
    • location object tells the message source:
      • url,
      • line,
      • column,
      • lineText.
    • className - (string) additional element class names for styling purposes.

Properties:

  • timestamp,

    Should we make timestamp part of the BaseMessage API?

  • category,

  • severity,

  • location,

  • repeatCount.

This message object can filter itself based on category, severity and text content. The message content is not allowed to be HTML by default to prevent potential breakage. HTML output shall be enabled on a case by case basis.

The repeatID property is populated such that only messages that have identical parent, textContent, category, severity, className and location are considered to be duplicates. Once a duplicate is found repeatCount is increased.

We can also keep track of the time stamps of each duplicate message, so we can do something for bug 722267. However I doubt we want to allow expand/collapse when messages are identical just to show different time stamps. If we have different messages that would need expansion then our duplicates matching logic is faulty and we need to fix our bugs, actually.

I think it is useful to show, on time stamp hover or click, the list of all time stamps of duplicates. Thoughts?

Notice that there's no explicit list of allowed categories or severities. That is left at the discretion of the implementers - UI and UX designers. This also up to each message implementation. Some types of messages are expected to force their own category/severity (for example ConsoleDir or NetworkRequest).

Do we want to allow messages to be constructed directly associated to a specific group? We could allow that. Are there use cases for this?

Class names and attributes for the message element:

  • A generic .message class name.
  • For category and severity we will use attributes, as per bug 628019.
  • For each message type we should have a class name that includes the message JavaScript class name, for example .message-Simple or .message-ConsoleDir.

We might need an onRender callback option in the constructor or an event rendered for this message object, to allow others to be notified when this message is displayed.

Should we just go ahead and define that now? Maybe in BaseMessage?

The BaseGroup API

The Messages.BaseGroup class extends BaseMessage to add grouping support. Each BaseGroup provides API to add messages and remove them from the group. Each type of group we will implement will extend the BaseGroup class.

Methods:

  • matchMessage(message) returns a boolean that tells if this group can display the given message object.
  • findGroupForMessage(message) returns the child group object that accepts the given message object. It goes through each this.groups and descendants (depth first search), from last to first, and it checks if group.matchMessage(message) returns true - first group that does so is returned.
  • addMessage(message) adds the given message to this group (which means message is added to this.messages). If message inherits from BaseGroup then the given object is also added to the this.groups array.
  • renderMessage(message) outputs the given message object this group container.
  • removeMessageFromQueue(message) removes the given message from the list of known messages.
  • removeMessage(message) removes the given message from output.

Properties:

  • groups is an array that holds each of the child group objects.
  • messages is an array that holds each of the child message objects rendered in this group object.
  • collapsed is a boolean that tells if this group is collapsed or not. This is also a setter that allows programmable open/close. When this value changes a groups-opened/groups-closed event is fired on the owning ConsoleOutput instance.

We want to be able to have any kind of groups, based on any criteria we may decide now or at a later time. Examples of message groups:

  • group messages by "context" - every page load.
  • group only console API calls within groups created by console.group().

This means that we need to allow out of order message insertion in the output, together with nested groups. For example a network request can happen while a console group is open which means it needs to show outside of it.

To add a group to the output you use the same API as adding a message: ConsoleOutput.addMessage(group). Groups are queued to be displayed like normal messages. Each new group we add to the output queue is also added at the end of the groups array.

Do note the following:

  • this document does not yet define any types of groups. This is new territory that we are charting and the desired UX is not well defined.
  • it is the author's intent to use a Group object for grouping JavascriptEvalInput and JavaScriptEvalOutput at implementation time.
  • we will also implement a Group object for ConsoleGroup.
  • when we fix bug 655700 it is the author's intent to experiment with using a Group object for every page reload, such that we can mark older messages as obsolete and collapse them.

The BaseWidget API

The BaseWidget class is meant to be the class that other widget classes extend from.

Methods:

  • constructor(message[, ...]) where message is the owning message object, followed by any widget-specific arguments.
  • render() is invoked when the owning message is displayed. This is also invoked when the widget needs to be displayed. This method returns its own object instance. The result of this method is cached - this.element will remain the same.
  • destroy() is invoked when the owning message is removed.

Properties:

  • message points to the owning message object.
  • element gives the DOM element of this widget, if it was ever rendered.
  • textContent holds the string representation for this widget.

Overview of message output

To better understand this section please look at the API details in the previous sections.

When you want to output a message you only pick the message type you want and provide whatever the constructor needs. You never call the message's init(), render() or onRemove() methods. You simply invoke output.addMessage(message) and the rest happens for you.

What happens when you invoke output.addMessage(message):

  • the output.groups array is walked to find the group that accepts the given message, using the output.findGroupForMessage() method.
  • we invoke group.addMessage(message) if we find a group, otherwise we skip this step.
  • we invoke message.init(output, group).
  • we send out the messages-added event if this is a new message.
  • when the time comes to render a message object (during output flushes) we do:
    • we check if this is a duplicate message.
      • if yes, we invoke originalMessage.onDuplicateAdded(duplicateMessage).
        • we skip to the next message in queue.
    • invoke let element = message.render(),
    • if this message is part of a group we invoke group.renderMessage(message).
      • otherwise we use the ConsoleOutput private method for rendering the message.
    • at the end we send three events: messages-added, messages-updated and messages-removed as defined in a previous section.

If a message needs to be pruned from the queue before it is rendered, then we invoke message.onRemoveFromQueue() then group.removeMessageFromQueue(message) if there's any group.

When a message needs to be removed from output, after it was rendered we do: message.onRemove() then group.removeMessage(message). If message is a group object itself we remove it only when it is empty, otherwise we skip it.

Implementation plan

We want to take bugs from the list of known issues and go through them, sorted by technical priorities. There will be no one big patch to rewrite everything. New APIs will be written and existing code will be converted to that as we fix bugs, step by step.

This section describes the list of bugs where work will happen to convert filtering, pruning, output queueing, and existing message types to the new APIs.

Do note that technical priorities means: patches with atomic changes to existing code that are sufficiently self-contained, which include changes that benefit other patches.

As we switch every message type to the new API we will also switch them to HTML, away from XUL elements.

Page navigation/reload issues

Status: completed.

See:

One quick win here is to reduce the load of messages users get in the console output.

For bug 793996 we will implement ConsoleOutput and Messages.NavigationMarker as minimal as possible.

You cannot select freely any text in the output

Status: completed.

See:

We need to break out of the use of xul:richlist for the output container. In this patch we will fix the two bugs listed above and we will break a number of tests that expect richlist-specific behavior and the current way of working with the clipboard. This will give us an opportunity to prepare tests to use the new waitForMessages() helper from head.js.

Once this patch lands we will be able to start converting existing message types to the new APIs, and we can make output improvements for each message.

This patch will have minimal API changes - focus here is on the DOM output changes which are enough to break tests and to change the Web Console's user experience. I do expect to remove HS_regroupOutput() to fix bug 746871.

Make console.dir() output collapsible, bug 792633

In this patch we will switch console.dir() messages to the new API. Minimal ConsoleOutput API will be implemented here, along with BaseMessage, Simple and ConsoleDir message objects. We will also implement the widgets needed for console.dir(): BaseWidget, MessageTimestamp, MessageSource and VariablesView. Minimal filtering and message repeats support with the new API is also planned.

While the Simple message object is implemented we need to not forget about:

  • add tooltip to the repeat bubble, bug 675487.
  • and the problems we have with clicking links and keyboard accessibility.

I do not expect much breakage in tests.

The console.trace() output should be prettier, bug 790309

Status: completed.

In this patch we will switch console.trace() to the new API. Gradual improvements to the ConsoleOutput APIs are expected as well. The ConsoleTrace message object and the Stacktrace widget will be implemented.

This patch paves the way for fixing bug 814497 as well.

Again, tests breakage should be minimal.

Links in errors/warnings cannot be clicked/copied, bug 663370

Here we will parse all links in style and script messages to make them links. We will transition the style and script message elements over to the new ConsoleOutput API. The Messages.ScriptError and Messages.StyleError objects will be implemented.

Here we need to keep in mind the following bugs:

  • display column number in addition to line numbers, bug 684096.
  • links can open using any mouse button, bug 653710.
  • clicking in blank areas of messages opens popups/sidebar, bug 773291.
  • better UX for all links in output, bug 776939.
  • accessibility: make clickable output keyboard accessible, bug 588010.

We need to fix the above list of bugs while we transition to the new API, for the style and script error messages.

Tests breakage should be moderate, given we have many tests that expect specific output format for errors and warnings.

Add support for %c style formatting, bug 823097

Also see:

  • display column number in addition to line numbers, bug 684096.
  • links can open using any mouse button, bug 653710.
  • clicking in blank areas of messages opens popups/sidebar, bug 773291.
  • better UX for all links in output, bug 776939.
  • accessibility: make clickable output keyboard accessible, bug 588010.

While we fix bug 823097 we also need to fix links in the remaining console API messages that we did not yet transition to the new API (console.log/info/warn/error/debug). Here we will do that, which means Messages.ConsoleGeneric will be implemented.

Tests breakage should be moderate, given we have many tests that expect specific output format for console API messages.

The console.group() output should allow collapse, bug 755534

Once we have transitioned all of the console API messages to the new API, we can finish with the implementation of Messages.BaseGroup and ConsoleGroup.

Tests breakage should be minimal. We have very few tests related to console.group().

Fix links in network messages

Status: mostly complete. Work happened in bug 760876.

This is about fixing all of the links-related bugs and keyboard accessibility issues for the network messages. The NetworkRequest message object will be implemented.

Tests breakage is expected to be medium.

Integrate the JSTerm input line with the Console Output area, bug 865708

While we fix this bug we can also migrate the JavaScript evaluation input and output messages to the new API. We need to make sure that links have good UX and they are keyboard accessible. Here we will implement Messages.JavaScriptEvalInput and Messages.JavaScriptEvalOutput.

Tests breakage is expected to be minimal to medium. We shouldn't have tests that are too picky about the JSTerm input location.

Done. Triage and cleanups.

At this point all of the existing messages will be transitioned to the new API. Now it is time to open a bug to clean up the code, to remove the legacy code. It is also time to triage bugs and mark existing bugs as fixed/wontfix.

From this point we shall re-evaluate priorities. What follows is a list of remaining bugs that are important to fix.

Group / gray out / mark as obsolete output from previous reloads, bug 655700

This should be easy to implement given all of the ConsoleOutput API will be ready.

Customized output for different types of objects

Status: completed.

  • DOM elements, bug 682033.
    • highlight nodes on hovering objects in the Console, bug 757866.
    • it would be ideal if the remote inspector lands first.
  • no syntax highlighting for JS and CSS, bug 584733.
    • I would like to reuse syntax highlighters from CodeMirror here, so we need it to land.
  • DOM enums, bug 762321.
  • other types of JS objects, bug 843004.

From Web Console's perspective we can fix these more easily at this point.

We should keep in mind that we want addons to be able to customize output for objects. Such APIs will be defined at a later point in time.

Add stack traces to every console API call and every script error, bug 814497

Script errors need to include the stackframes, at Gecko level. This means changes to the nsIScriptError interface is needed and we need to also make changes to the most important places where such script errors are logged throughout Gecko.

For the console API messages this is easier: we can use Components.stack in ConsoleAPI.js to get the full stack trace. However, we have known performance issues, see bug 762995.

To fix this bug at the Web Console level we will have all the needed pieces ready, with the new ConsoleOutput API.

Breakage of existing tests is expected to be minimal.

vim:set ft=markdown:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment