CSC/ECE 517 Fall 2014/oss M1453 sst: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(23 intermediate revisions by 3 users not shown)
Line 3: Line 3:


==Background Information==
==Background Information==
Firefox supports remote debugging - i.e. communicating with an arbitrary server that implements a protocol for exposing information about web content. Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the DOM tree in the document inspector. We want to expand these capabilities by allowing remote modification of the DOM tree, better JS console integration (exposing historical and real-time exceptions), and enabling server->client messages that are not responses to client->server messages.
Firefox supports remote debugging - i.e. communicating with an arbitrary server that implements a protocol for exposing information about web content. Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the [http://en.wikipedia.org/wiki/Document_Object_Model DOM] tree in the document inspector. We want to expand these capabilities by allowing remote modification of the [http://en.wikipedia.org/wiki/Document_Object_Model DOM] tree, better JS console integration (exposing historical and real-time exceptions), and enabling server->client messages that are not responses to client->server messages.


===Developer tools===
===Developer tools===
The Mozilla debugging protocol allows a debugger to connect to a browser, discover what sorts of things are present to debug or inspect, select [http://en.wikipedia.org/wiki/JavaScript JavaScript] threads to watch, and observe and modify their execution. The protocol provides a unified view of JavaScript, [http://en.wikipedia.org/wiki/Document_Object_Model DOM] nodes, [http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS] rules, and the other technologies used in client-side web applications. The protocol ought to be sufficiently general to be extended for use with other sorts of clients (profilers, say) and servers (mail readers; random XULrunner applications).
The Mozilla debugging protocol allows a debugger to connect to a browser, discover what sorts of things are present to debug or inspect, select [http://en.wikipedia.org/wiki/JavaScript JavaScript] threads to watch, and observe and modify their execution. The protocol provides a unified view of JavaScript, [http://en.wikipedia.org/wiki/Document_Object_Model DOM] nodes, [http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS] rules, and the other technologies used in client-side web applications. The protocol ought to be sufficiently general to be extended for use with other sorts of clients (profilers, say) and servers (mail readers; random [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner XULrunner] applications). <ref name="Remote debugging tools in Mozilla">https://wiki.mozilla.org/Remote_Debugging_Protocol</ref>


All communication between debugger (client) and browser (server) is in the form of [http://en.wikipedia.org/wiki/JSON JSON] objects. This makes the protocol directly readable by humans, capable of graceful evolution, and easy to implement using stock libraries. In particular, it should be easy to create mock implementations for testing and experimentation.
All communication between debugger (client) and browser (server) is in the form of [http://en.wikipedia.org/wiki/JSON JSON] objects. This makes the protocol directly readable by humans, capable of graceful evolution, and easy to implement using stock libraries. In particular, it should be easy to create mock implementations for testing and experimentation.


The protocol operates at the JavaScript level, not at the [http://en.wikipedia.org/wiki/C%2B%2B C++] or machine level, and assumes that the JavaScript implementation itself is healthy and responsive. The JavaScript program being executed may well have gone wrong, but the JavaScript implementation's internal state must not be corrupt. Bugs in the implementation may cause the debugger to fail; bugs in the interpreted program must not.
The protocol operates at the JavaScript level, not at the [http://en.wikipedia.org/wiki/C%2B%2B C++] or machine level, and assumes that the JavaScript implementation itself is healthy and responsive. The JavaScript program being executed may well have gone wrong, but the JavaScript implementation's internal state must not be corrupt. Bugs in the implementation may cause the debugger to fail; bugs in the interpreted program must not.
Reference: https://wiki.mozilla.org/Remote_Debugging_Protocol


'''Setting up remote debugging'''
'''Setting up remote debugging'''


Firefox acts as the client and provides the user interface to control the developer tools for Thunderbird. Its best to use a Firefox and Thunderbird version with a matching major version number, but in some cases it will work even with differing versions.
Firefox acts as the client and provides the user interface to control the developer tools. The guide to explain how to use remote debugging to inspect or debug code running in Firefox is [https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Thunderbird here]
 
The guide to explain how to use remote debugging to inspect or debug code running in Firefox is [https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Thunderbird here]


===Servo===
===Servo===
Line 33: Line 29:
There are a number of ways to install Rust, but the easiest is to use the rustup script. If you're on Linux or a Mac, all you need to do is this:
There are a number of ways to install Rust, but the easiest is to use the rustup script. If you're on Linux or a Mac, all you need to do is this:
     $ curl -s https://static.rust-lang.org/rustup.sh | sudo sh
     $ curl -s https://static.rust-lang.org/rustup.sh | sudo sh
(If you're concerned about curl | sudo sh, check references)
(If you're concerned about curl | sudo sh, check references).<ref name="building-from-source">https://github.com/rust-lang/rust</ref><ref name="lang-install">http://www.rust-lang.org/install.html</ref>
If you're on Windows, please download either the 32-bit installer or the 64-bit installer and run it.
If you're on Windows, please download either the 32-bit installer or the 64-bit installer and run it.


Line 40: Line 36:


If you used the Windows installer, just re-run the .exe and it will give you an uninstall option.
If you used the Windows installer, just re-run the .exe and it will give you an uninstall option.
Reference : http://doc.rust-lang.org
Download Rust at: http://www.rust-lang.org/


==Project Description==
==Project Description==
===Installing dependencies for Servo===
===Installing dependencies for Servo===
The following are the commands to install dependencies for servo on different platforms:<ref name="Installing servo">https://github.com/servo/servo</ref>
On OS X (homebrew):
On OS X (homebrew):
     brew install automake pkg-config python glfw3 cmake
     brew install automake pkg-config python glfw3 cmake
Line 80: Line 73:
     sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake
     sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake


Reference :https://github.com/servo/servo
===Building Servo===
'''Usage'''
 
mach [global arguments] build [command arguments]


===Building Servo===
'''Global Arguments'''
[[File:Play framework components.png|frame|right|alt=Components of Play framework.|Components of Play framework]]
 
  -v, --verbose        Print verbose output.
  -l FILENAME, --log-file FILENAME
                        Filename to write log data to.
  --log-interval        Prefix log line with interval from last message rather
                        than relative time. Note that this is NOT execution
                        time if there are parallel operations.
  --log-no-times        Do not prefix log lines with times. By default, mach
                        will prefix each output line with the time since
                        command start.
  -h, --help            Show this help message.
 
'''Command Arguments'''
  --target TARGET, -t TARGET
                        Cross compile for given target platform
  --release, -r        Build in release mode
  --jobs JOBS, -j JOBS  Number of jobs to run in parallel
  --android            Build for Android
  --verbose, -v        Print verbose output


===Running Servo===
===Running Servo===
'''Usage'''
mach [global arguments] run [command arguments]
'''Global Arguments'''
  -v, --verbose        Print verbose output.
  -l FILENAME, --log-file FILENAME
                        Filename to write log data to.
  --log-interval        Prefix log line with interval from last message rather
                        than relative time. Note that this is NOT execution
                        time if there are parallel operations.
  --log-no-times        Do not prefix log lines with times. By default, mach
                        will prefix each output line with the time since
                        command start.
  -h, --help            Show this help message.
'''Command Arguments'''
<pre>
params  Command-line arguments to be passed through to Servo
</pre>


==Implementation==
==Implementation==
Line 104: Line 139:
'''Storing and exiting connections'''
'''Storing and exiting connections'''


The accepted streams were stored in a <code>Vector</code> in the <code>devtools/lib.rs</code> file. On the exit of Servo the corresponding read and write end of the stream were closed successfully.
The accepted streams were stored in a <code>Mutable Vector</code> in the <code>devtools/lib.rs</code> file. On the exit of Servo the corresponding read and write end of the stream were closed successfully.


The following two files were modified to include the new code.
The following two files were modified to include the new code.


:*'''[https://github.com/shanil-puri/servo/blob/master/components/compositing/constellation.rs constellation.rs]'''
:*'''[https://github.com/shanil-puri/servo/blob/ServoExitDevtools/components/compositing/constellation.rs constellation.rs]'''
:*'''[https://github.com/shanil-puri/servo/blob/master/components/devtools/lib.rs devtools/lib.rs]'''
:*'''[https://github.com/shanil-puri/servo/blob/ServoExitDevtools/components/devtools/lib.rs devtools/lib.rs]'''


==Future Scope==
==Future Scope==

Latest revision as of 01:32, 11 November 2014

Expand the coverage of the developer tools for inspecting web content in Servo remotely from a Firefox browser - requires the ability to read JavaScript code in Firefox


Background Information

Firefox supports remote debugging - i.e. communicating with an arbitrary server that implements a protocol for exposing information about web content. Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the DOM tree in the document inspector. We want to expand these capabilities by allowing remote modification of the DOM tree, better JS console integration (exposing historical and real-time exceptions), and enabling server->client messages that are not responses to client->server messages.

Developer tools

The Mozilla debugging protocol allows a debugger to connect to a browser, discover what sorts of things are present to debug or inspect, select JavaScript threads to watch, and observe and modify their execution. The protocol provides a unified view of JavaScript, DOM nodes, CSS rules, and the other technologies used in client-side web applications. The protocol ought to be sufficiently general to be extended for use with other sorts of clients (profilers, say) and servers (mail readers; random XULrunner applications). <ref name="Remote debugging tools in Mozilla">https://wiki.mozilla.org/Remote_Debugging_Protocol</ref>

All communication between debugger (client) and browser (server) is in the form of JSON objects. This makes the protocol directly readable by humans, capable of graceful evolution, and easy to implement using stock libraries. In particular, it should be easy to create mock implementations for testing and experimentation.

The protocol operates at the JavaScript level, not at the C++ or machine level, and assumes that the JavaScript implementation itself is healthy and responsive. The JavaScript program being executed may well have gone wrong, but the JavaScript implementation's internal state must not be corrupt. Bugs in the implementation may cause the debugger to fail; bugs in the interpreted program must not.

Setting up remote debugging

Firefox acts as the client and provides the user interface to control the developer tools. The guide to explain how to use remote debugging to inspect or debug code running in Firefox is here

Servo

Servo is an experimental web browser engine under development by Mozilla Research. It is an ambitious project aimed at rebuilding the browser on modern parallel hardware. Servo aims at addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web. Servo is written in Rust, a new type safe, systems language which is authored by Mozilla.

Mozilla has paired up with Samsung which will port this advanced technology Web browser engine to Android and ARM. Samsung will contribute a ARM back end to Rust and the necessary infrastructure to cross-compile to Android along with other improvements.

The mission of the experimental engine is to take advantage of tomorrow’s faster, multi-core, heterogeneous computing architectures. The prototype seeks to create a highly parallel environment, in which typical web browser components such as rendering, layout, HTML parsing, image decoding will be handled by specific and disjoint tasks, thus achieving the objective of optimal usage of parallel architecture.

Rust

Rust is a new programming language designed to support concurrency and parallelism in building platforms both in functional and object-oriented paradigms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. There are a number of ways to install Rust, but the easiest is to use the rustup script. If you're on Linux or a Mac, all you need to do is this:

    $ curl -s https://static.rust-lang.org/rustup.sh | sudo sh

(If you're concerned about curl | sudo sh, check references).<ref name="building-from-source">https://github.com/rust-lang/rust</ref><ref name="lang-install">http://www.rust-lang.org/install.html</ref> If you're on Windows, please download either the 32-bit installer or the 64-bit installer and run it.

Uninstalling Rust

   $ curl -s https://static.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall

If you used the Windows installer, just re-run the .exe and it will give you an uninstall option.

Project Description

Installing dependencies for Servo

The following are the commands to install dependencies for servo on different platforms:<ref name="Installing servo">https://github.com/servo/servo</ref>

On OS X (homebrew):

    brew install automake pkg-config python glfw3 cmake
    pip install virtualenv


On OS X (MacPorts):

    sudo port install python27 py27-virtualenv cmake


On Debian-based Linuxes:

   sudo apt-get install curl freeglut3-dev \
   libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
   msttcorefonts gperf g++ cmake python-virtualenv \
   libssl-dev libglfw-dev


On Fedora:

   sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
   freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
   fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
   rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd


On Arch Linux:

   sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake

Building Servo

Usage

mach [global arguments] build [command arguments]

Global Arguments

 -v, --verbose         Print verbose output.
 -l FILENAME, --log-file FILENAME
                       Filename to write log data to.
 --log-interval        Prefix log line with interval from last message rather
                       than relative time. Note that this is NOT execution
                       time if there are parallel operations.
 --log-no-times        Do not prefix log lines with times. By default, mach
                       will prefix each output line with the time since
                       command start.
 -h, --help            Show this help message.

Command Arguments

 --target TARGET, -t TARGET
                       Cross compile for given target platform
 --release, -r         Build in release mode
 --jobs JOBS, -j JOBS  Number of jobs to run in parallel
 --android             Build for Android
 --verbose, -v         Print verbose output

Running Servo

Usage

mach [global arguments] run [command arguments]

Global Arguments

 -v, --verbose         Print verbose output.
 -l FILENAME, --log-file FILENAME
                       Filename to write log data to.
 --log-interval        Prefix log line with interval from last message rather
                       than relative time. Note that this is NOT execution
                       time if there are parallel operations.
 --log-no-times        Do not prefix log lines with times. By default, mach
                       will prefix each output line with the time since
                       command start.
 -h, --help            Show this help message.

Command Arguments

params  Command-line arguments to be passed through to Servo

Implementation

This project mainly aims at expanding the remote debugging capabilities provided by Servo. The current implementation provides a developer tools server which currently supports executing JS remotely and investigating the DOM tree in the document inspector. The scope of this project is to expand the coverage of remote debugging capabilities. These include:

  • remote modification of the DOM tree
  • better exposure of exception in JS console
  • enable Server-Client messages.

Work done in Part 1

Build Servo

Setup a local instance of Servo. Install the dependencies and successfully build Servo. Reproduce the problem of Servo window getting hung up when opened with an instance of devtools.

Fixing the issue of successful Servo Exit

This issue was fixed by sending an Exit message to the developer tools. On browser close, a ServerExitMsg message is sent from the handle_exit method in the constellation.rs file.

Storing and exiting connections

The accepted streams were stored in a Mutable Vector in the devtools/lib.rs file. On the exit of Servo the corresponding read and write end of the stream were closed successfully.

The following two files were modified to include the new code.

Future Scope

  • Separate devtools event handling from script handling tasks.
  • Implement client server messages to update the attribute values of a HTML node.
  • Send a console message to the developer tools server.
  • Synchronously fetch the cached messages from tasks.
  • Create an error reporter for error logging and notification.
  • Dynamic buffering and sending of messages to Developer Tools.
  • Support for disparate client reading and writing.
  • Send a detailed error message to the client when an error is reported to the tasks.

References

<references/>