Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-10T16:48:46Z

Ssrivas8: /* Test Plan */

''' Mutation Observer API Project with SERVO & RUST '''

[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is a prototype web browser engine written in the [http://en.wikipedia.org/wiki/JavaScript RUST] language. The [https://en.wikipedia.org/wiki/Document_Object_Model DOM] standard defines a MutationObserver API that allows web content to receive callbacks when the page contents are mutated. In simple words, MutationObserver facilitates the developers with a technique to react to the changes in DOM. MutationObserver is designed to replace the Mutation Events defined in the DOM3 Events specification. The goal of this project is to implement the fundamental pieces required to support the Mutation Observer API.

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source web browser engine designed for application and embedded use. It is a high performance browser engine created by Mozilla Research and is written in the Rust language. The main idea behind the Servo is to create a parallel environment where the components are handle by isolated and fine grained tasks. These components can be rendering, HTML parsing etc.

===Rust===
[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Setting up and Building the Project'''==
Follow the Guidelines mentioned in the [https://github.com/srivassumit/servo/wiki/Readme read me] page of the project's Wiki Page for building the Project in a Linux Environment.

=='''Project Description'''==
The purpose of this project is to implement the basic functionality required to implement a [https://dom.spec.whatwg.org/#mutation-observers Mutation Observer API] as defined in the [https://dom.spec.whatwg.org DOM] Specifications.
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project], we implemented the initial Steps as described in the [https://github.com/servo/servo/wiki/Mutation-observer-project Project Specification]. The initial implementation is merged in the original Servo Repository and the code can be found [https://github.com/servo/servo/commit/107ac9ab56c1a4cee3e5f9828f91ab394e3e8eee here].
For the next phase of the project, we have to implement the functionality for supporting Mutation Observers.
Based on the Project description, we have made a Project Design, which is described in detail below.

=='''Project Design'''==

===High Level Design===
Our Project Implements the Mutation Observer API in the Mozilla's Servo Browser Engine. The High Level Design for the same is described below:

===Technical Design===

====Add support for mutation observer microtasks====

*We will add a <code>mutation_observer_compound_microtask_queued</code> member to the <code>ScriptThread</code> class. This will be used later to implement the algorithm for ''queuing a mutation observer compound microtask'' and ''notifying a mutation observer'' as described below.

*Then, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask queue a mutation observer compound microtask algorithm] by adding a new variant to the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/microtask.rs#29 Microtask] enum for mutation observers. The algorithm for doing that is described below:
1) If the ''mutation observer compound microtask queued'' flag is set, then return.
2) Set the ''mutation observer compound microtask queued'' flag.
3) [https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask Queue] a [https://html.spec.whatwg.org/multipage/webappapis.html#compound-microtask compound microtask] which will be used to notify the mutation observers.

*Next, we will implement the [https://dom.spec.whatwg.org/#notify-mutation-observers notify mutation observers algorithm] using the vector of observers previously added to the <code>ScriptThread</code> class. The notify mutation observers algorithm is implemented as described below:
1) Unset the ''mutation observer compound microtask queued'' flag, which was set in the previous algorithm.
2) Declare ''notifyList'' to be a copy of ''unit of related similar-origin browsing contexts''' list of MutationObserver objects.
3) Declare ''signalList'' to be a copy of ''unit of related similar-origin browsing contexts''' [https://dom.spec.whatwg.org/#signal-slot-list signal slot list].
4) Empty the ''unit of related similar-origin browsing contexts''' signal slot list.
5) For each MutationObserver object ''mo'' in ''notifyList'', we shall execute a ''compound microtask subtask'' to run these steps:
1) Declare ''queue'' to contain ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
2) Empty ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
3) All transient registered observers whose observer is ''mo'' will be removed.
4) If ''queue'' is non-empty, then invoke ''mo''’s callback with a list of arguments consisting of <code>queue</code> and ''mo'', and ''mo'' as the [https://heycam.github.io/webidl/#dfn-callback-this-value callback this value].
If this throws an exception, then we will report the exception.
6) For each ''[https://dom.spec.whatwg.org/#concept-slot slot]'' in ''signalList'', an event named ''slotchange'' will be fired in the same order as it is stored in the <code>signalist</code>,
with its ''[https://dom.spec.whatwg.org/#dom-event-bubbles bubbles]'' attribute set to ''true'', at ''slot''.

====Add support for observing specific mutations====
*Firstly we will add a vector of <code>MutationObserver</code> objects to <code>Node</code> to store the Mutation Observers.
*Then we will implement the [https://dom.spec.whatwg.org/#dom-mutationobserver-observe observe] method of MutationObserver. As per the DOM specification, the observe method has the following behaviour:
1) If either ''options''’ ''attributeOldValue'' or ''attributeFilter'' is present and ''options''’ ''attributes'' is omitted, then we set the ''options''’ ''attributes''
to true.
2) If options’ ''characterDataOldValue'' is present and options’ ''characterData'' is omitted, then we set options’ ''characterData'' to true.
3) If none of options’ ''childList'', attributes, and ''characterData'' is true, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
4) If options’ ''attributeOldValue'' is true and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
5) If options’ ''attributeFilter'' is present and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
6) If options’ ''characterDataOldValue'' is true and options’ ''characterData'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
7) For each [https://dom.spec.whatwg.org/#registered-observer registered observers] "''registered''" in target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] whose '''observer''' is the context object we perform the
following steps:
1) We remove all [https://dom.spec.whatwg.org/#transient-registered-observer transient registered observers] whose '''source''' is "''registered''".
2) We also replace ''registered''’s '''options''' with options.
8) Otherwise, we add a new [https://dom.spec.whatwg.org/#registered-observer registered observers] to target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] with the [https://dom.spec.whatwg.org/#context-object context object] as the observer and ''options''
as the options, and then also, we add target to [https://dom.spec.whatwg.org/#context-object context object]’s list of [https://dom.spec.whatwg.org/#concept-node node] on which it is registered.
'''Note''': Steps 7 and 8 in the above description means that we replace an existing matching entry with the new options, or add a new entry if there is no match.

*Next, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record algorithm]. Which is described as follows:
1) Declare the ''interested'' observers initially as an empty set of [https://dom.spec.whatwg.org/#mutationobserver MutationObserver] objects optionally paired with a string.
2) Declare ''nodes'' be the [https://dom.spec.whatwg.org/#concept-tree-inclusive-ancestor inclusive ancestors] of target.
3) For each ''node'' in nodes, and then for each ''registered observer'' (with ''registered observer''’s '''options''' as ''options'') in node’s list of
[https://dom.spec.whatwg.org/#registered-observer registered observers] we decide:
1) If none of the following are true
1) ''node'' is not target and ''options''’ subtree is false
2) ''type'' is "''attributes''" and ''options''’ ''attributes'' is not true
3) ''type'' is "''attributes''", ''options''’ ''attributeFilter'' is present, and ''options''’ ''attributeFilter'' does not contain name or namespace is non-null
4) ''type'' is "''characterData''" and ''options''’ ''characterData'' is not true
5) ''type'' is "''childList''" and ''options''’ ''childList'' is false
then,:
1) If ''registered observer''’s '''observer''' is not in ''interested'' observers, we append ''registered observer''’s '''observer''' to ''interested observers''.
2) If either type is "''attributes''" and ''options''’ ''attributeOldValue'' is true, or type is "''characterData''" and ''options''’
''characterDataOldValue'' is true,we set the paired string of ''registered observer''’s '''observer''' in ''interested observers'' to ''oldValue''.
4) For each ''observer'' in ''interested observers'':
1) Declare ''record'' to be a new [https://dom.spec.whatwg.org/#mutationrecord MutationRecord] object with its [https://dom.spec.whatwg.org/#dom-mutationrecord-type type] set to ''type'' and [https://dom.spec.whatwg.org/#dom-mutationrecord-target target] set to ''target''.
2) If ''name'' and ''namespace'' are given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributename attributeName] to ''name'', and ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributenamespace attributeNamespace] to ''namespace''.
3) If ''addedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-addednodes addedNodes] to ''addedNodes''.
4) If ''removedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-removednodes removedNodes] to ''removedNodes'',
5) If ''previousSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-previoussibling previousSibling] to ''previousSibling''.
6) If ''nextSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-nextsibling nextSibling] to ''nextSibling''.
7) If ''observer'' has a paired string, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-oldvalue oldValue] to ''observer''’s paired string.
8) Then, append ''record'' to ''observer''’s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
5) [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask Queue a mutation observer compound microtask].

*We will make [https://dom.spec.whatwg.org/#concept-element-attributes-change changing]/[https://dom.spec.whatwg.org/#concept-element-attributes-append appending]/[https://dom.spec.whatwg.org/#concept-element-attributes-remove removing]/[https://dom.spec.whatwg.org/#concept-element-attributes-replace replacing] of an attribute, queue a mutation record via the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/attr.rs#171 Attr::set_value], [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#955 Element::push_attribute], and [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#1077 Element::remove_first_matching_attribute] attributes. These changes are performed in the following steps:
**If we want to '''change''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an [https://dom.spec.whatwg.org/#concept-element element] ''element'' to value, we run these steps:
1) [https://dom.spec.whatwg.org/#queue-a-mutation-record Queue a mutation record] of "attributes" for element with name attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], namespace attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace], and oldValue
attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value].
2) If ''element'' is [https://dom.spec.whatwg.org/#concept-element-custom custom], we [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with ''element'', callback name "''attributeChangedCallback''", and an
argument list containing ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], value, and ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
3) We then run the[https://dom.spec.whatwg.org/#concept-element-attributes-change-ext attribute change steps] with ''element'', ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], ''value'', and ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
4) We set ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value] to ''value''.

**If we want to '''append''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' to an [https://dom.spec.whatwg.org/#concept-element element] ''element'', we run these steps:
1) We[https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record] of "''attributes''" for ''element'' with name ''attribute''’s[https://dom.spec.whatwg.org/#concept-attribute-local-name local name], namespace ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace], and ''oldValue''
null.
2) If ''element'' is [https://dom.spec.whatwg.org/#concept-element-custom custom], we [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with ''element'', callback name "''attributeChangedCallback''", and an
argument list containing ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], null, ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
3) We then run the attribute change steps with element, attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], null, attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and attribute’s namespace.
4) We also [https://infra.spec.whatwg.org/#list-append append] ''attribute'' to ''element''’s [https://dom.spec.whatwg.org/#concept-element-attribute attribute list].
5) We then set ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to ''element''.

**If we want to '''remove''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an [https://dom.spec.whatwg.org/#concept-element element] ''element'', we run these steps:
1) We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace], and oldValue
attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value].
2) If element is [https://dom.spec.whatwg.org/#concept-element-custom custom], we then [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with element, callback name "attributeChangedCallback", and an
argument list containing attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value], null, and attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
3) We run the attribute change steps with element, attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value], null, and attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
4) We then remove attribute from element’s attribute list.
5) We set attribute’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to null.

**If we want to '''replace''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''oldAttr'' by an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''newAttr'' in an [https://dom.spec.whatwg.org/#concept-element element] ''element'', run these steps:
1) We[https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record] of "''attributes''" for ''element'' with name ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name],[https://dom.spec.whatwg.org/#concept-attribute-namespace namespace] ''oldAttr''’s namespace, and oldValue
''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value].
2) If element is [https://dom.spec.whatwg.org/#concept-element-custom custom], we then [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with element, callback name "attributeChangedCallback", and an
argument list containing ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], ''newAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and ''oldAttr''’s namespace.
3) We run the attribute change steps with element, ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], ''newAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and ''oldAttr''’s namespace.
4) We then [https://infra.spec.whatwg.org/#list-replace replace] ''oldAttr'' by ''newAttr'' in element’s [https://dom.spec.whatwg.org/#concept-element-attribute attribute list].
5) We set ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to null.
6) We set ''newAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to ''element''.

=='''Test Plan'''==
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project],, our tests were written with regard to attributes, Childlist, Character data and records of a Mutation Observer. These tests are present in web-platform-tests directory (i.e <code>.tests/wpt/web-platform-tests/dom/nodes</code>).

The project owner from Mozilla has [https://github.com/servo/servo/issues/6633#issuecomment-292680210 mentioned] that the existing tests will provide enough coverage for the newly added code as well. Furthermore, it was advised to create simple tests using the following steps:

1) The simplest way to create a new test is to use the following command: ./mach create-wpt tests/wpt/path/to/new/test.html.
2) This will create test.html in the appropriate directory using the WPT template for JavaScript tests. Tests are written using testharness.js.
3) To create a new reference test instead, use the following:
./mach create-wpt --reftest tests/wpt/path/to/new/reftest.html --reference tests/wpt/path/to/reference.html
4) reference.html will be created if it does not exist, and reftest.html will be created using the WPT reftest template.
5) These new tests can then be run in the following manner like any other WPT test: ./mach test-wpt tests/wpt/path/to/new/test.html and
./mach test-wpt tests/wpt/path/to/new/reftest.html

For this part of the project, our test plan is to check the following:
*Test the micro task for mutation observer.
**Check if microtask queued flag is initially unset.
**Check if the task returns on setting the microtask queued flag.
**On notifying mutation observers, check if microtask queued flag is unset.
**Check the size of record queue on notifying mutation observers.
**Check if the number of events fired is equal to number of slots in Signal list.

*Test the observation of specific mutations:
**Whenever an observe method is invoked and attributeOldValue or attributeFilter is present and attributes is omitted, check if attributes is set to true.
**Whenever an observe method is invoked and characterDataOldValue is present and characterData is omitted, check if characterData is set to true.
**Whenever an observe method is invoked and a TypeError is thrown, check if atleast one of the following scenarios are true.
***If none of options’ childList, attributes, and characterData is true.
***attributeOldValue is true and attributes is false.
***attributeFilter is present and attributes is false.
***characterDataOldValue is true and characterData is false.

===Running the Tests===

The web-platform tests can be run by giving the following command at the root directory of the project:
./mach test-wpt tests/wpt/web-platform-tests/dom/nodes.
We have Updated the corresponding test expectations as per the given [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations guidelines] in the <code>tests/wpt/metadata/dom/nodes/</code> directory.

=='''Design Pattern'''==
Our Project follows the [https://en.wikipedia.org/wiki/Observer_pattern Observer Pattern], where a list of the objects dependent on the current object is maintained and the dependents are notified of any state changes. The Mutation Observer helps in achieving this functionality.

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo 
5. https://github.com/servo/servo/wiki/Mutation-observer-project 
6. https://dom.spec.whatwg.org/

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-10T16:45:50Z

Ssrivas8: /* Project Design */ added sections fo high level and technical design

''' Mutation Observer API Project with SERVO & RUST '''

[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is a prototype web browser engine written in the [http://en.wikipedia.org/wiki/JavaScript RUST] language. The [https://en.wikipedia.org/wiki/Document_Object_Model DOM] standard defines a MutationObserver API that allows web content to receive callbacks when the page contents are mutated. In simple words, MutationObserver facilitates the developers with a technique to react to the changes in DOM. MutationObserver is designed to replace the Mutation Events defined in the DOM3 Events specification. The goal of this project is to implement the fundamental pieces required to support the Mutation Observer API.

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source web browser engine designed for application and embedded use. It is a high performance browser engine created by Mozilla Research and is written in the Rust language. The main idea behind the Servo is to create a parallel environment where the components are handle by isolated and fine grained tasks. These components can be rendering, HTML parsing etc.

===Rust===
[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Setting up and Building the Project'''==
Follow the Guidelines mentioned in the [https://github.com/srivassumit/servo/wiki/Readme read me] page of the project's Wiki Page for building the Project in a Linux Environment.

=='''Project Description'''==
The purpose of this project is to implement the basic functionality required to implement a [https://dom.spec.whatwg.org/#mutation-observers Mutation Observer API] as defined in the [https://dom.spec.whatwg.org DOM] Specifications.
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project], we implemented the initial Steps as described in the [https://github.com/servo/servo/wiki/Mutation-observer-project Project Specification]. The initial implementation is merged in the original Servo Repository and the code can be found [https://github.com/servo/servo/commit/107ac9ab56c1a4cee3e5f9828f91ab394e3e8eee here].
For the next phase of the project, we have to implement the functionality for supporting Mutation Observers.
Based on the Project description, we have made a Project Design, which is described in detail below.

=='''Project Design'''==

===High Level Design===
Our Project Implements the Mutation Observer API in the Mozilla's Servo Browser Engine. The High Level Design for the same is described below:

===Technical Design===

====Add support for mutation observer microtasks====

*We will add a <code>mutation_observer_compound_microtask_queued</code> member to the <code>ScriptThread</code> class. This will be used later to implement the algorithm for ''queuing a mutation observer compound microtask'' and ''notifying a mutation observer'' as described below.

*Then, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask queue a mutation observer compound microtask algorithm] by adding a new variant to the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/microtask.rs#29 Microtask] enum for mutation observers. The algorithm for doing that is described below:
1) If the ''mutation observer compound microtask queued'' flag is set, then return.
2) Set the ''mutation observer compound microtask queued'' flag.
3) [https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask Queue] a [https://html.spec.whatwg.org/multipage/webappapis.html#compound-microtask compound microtask] which will be used to notify the mutation observers.

*Next, we will implement the [https://dom.spec.whatwg.org/#notify-mutation-observers notify mutation observers algorithm] using the vector of observers previously added to the <code>ScriptThread</code> class. The notify mutation observers algorithm is implemented as described below:
1) Unset the ''mutation observer compound microtask queued'' flag, which was set in the previous algorithm.
2) Declare ''notifyList'' to be a copy of ''unit of related similar-origin browsing contexts''' list of MutationObserver objects.
3) Declare ''signalList'' to be a copy of ''unit of related similar-origin browsing contexts''' [https://dom.spec.whatwg.org/#signal-slot-list signal slot list].
4) Empty the ''unit of related similar-origin browsing contexts''' signal slot list.
5) For each MutationObserver object ''mo'' in ''notifyList'', we shall execute a ''compound microtask subtask'' to run these steps:
1) Declare ''queue'' to contain ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
2) Empty ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
3) All transient registered observers whose observer is ''mo'' will be removed.
4) If ''queue'' is non-empty, then invoke ''mo''’s callback with a list of arguments consisting of <code>queue</code> and ''mo'', and ''mo'' as the [https://heycam.github.io/webidl/#dfn-callback-this-value callback this value].
If this throws an exception, then we will report the exception.
6) For each ''[https://dom.spec.whatwg.org/#concept-slot slot]'' in ''signalList'', an event named ''slotchange'' will be fired in the same order as it is stored in the <code>signalist</code>,
with its ''[https://dom.spec.whatwg.org/#dom-event-bubbles bubbles]'' attribute set to ''true'', at ''slot''.

====Add support for observing specific mutations====
*Firstly we will add a vector of <code>MutationObserver</code> objects to <code>Node</code> to store the Mutation Observers.
*Then we will implement the [https://dom.spec.whatwg.org/#dom-mutationobserver-observe observe] method of MutationObserver. As per the DOM specification, the observe method has the following behaviour:
1) If either ''options''’ ''attributeOldValue'' or ''attributeFilter'' is present and ''options''’ ''attributes'' is omitted, then we set the ''options''’ ''attributes''
to true.
2) If options’ ''characterDataOldValue'' is present and options’ ''characterData'' is omitted, then we set options’ ''characterData'' to true.
3) If none of options’ ''childList'', attributes, and ''characterData'' is true, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
4) If options’ ''attributeOldValue'' is true and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
5) If options’ ''attributeFilter'' is present and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
6) If options’ ''characterDataOldValue'' is true and options’ ''characterData'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
7) For each [https://dom.spec.whatwg.org/#registered-observer registered observers] "''registered''" in target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] whose '''observer''' is the context object we perform the
following steps:
1) We remove all [https://dom.spec.whatwg.org/#transient-registered-observer transient registered observers] whose '''source''' is "''registered''".
2) We also replace ''registered''’s '''options''' with options.
8) Otherwise, we add a new [https://dom.spec.whatwg.org/#registered-observer registered observers] to target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] with the [https://dom.spec.whatwg.org/#context-object context object] as the observer and ''options''
as the options, and then also, we add target to [https://dom.spec.whatwg.org/#context-object context object]’s list of [https://dom.spec.whatwg.org/#concept-node node] on which it is registered.
'''Note''': Steps 7 and 8 in the above description means that we replace an existing matching entry with the new options, or add a new entry if there is no match.

*Next, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record algorithm]. Which is described as follows:
1) Declare the ''interested'' observers initially as an empty set of [https://dom.spec.whatwg.org/#mutationobserver MutationObserver] objects optionally paired with a string.
2) Declare ''nodes'' be the [https://dom.spec.whatwg.org/#concept-tree-inclusive-ancestor inclusive ancestors] of target.
3) For each ''node'' in nodes, and then for each ''registered observer'' (with ''registered observer''’s '''options''' as ''options'') in node’s list of
[https://dom.spec.whatwg.org/#registered-observer registered observers] we decide:
1) If none of the following are true
1) ''node'' is not target and ''options''’ subtree is false
2) ''type'' is "''attributes''" and ''options''’ ''attributes'' is not true
3) ''type'' is "''attributes''", ''options''’ ''attributeFilter'' is present, and ''options''’ ''attributeFilter'' does not contain name or namespace is non-null
4) ''type'' is "''characterData''" and ''options''’ ''characterData'' is not true
5) ''type'' is "''childList''" and ''options''’ ''childList'' is false
then,:
1) If ''registered observer''’s '''observer''' is not in ''interested'' observers, we append ''registered observer''’s '''observer''' to ''interested observers''.
2) If either type is "''attributes''" and ''options''’ ''attributeOldValue'' is true, or type is "''characterData''" and ''options''’
''characterDataOldValue'' is true,we set the paired string of ''registered observer''’s '''observer''' in ''interested observers'' to ''oldValue''.
4) For each ''observer'' in ''interested observers'':
1) Declare ''record'' to be a new [https://dom.spec.whatwg.org/#mutationrecord MutationRecord] object with its [https://dom.spec.whatwg.org/#dom-mutationrecord-type type] set to ''type'' and [https://dom.spec.whatwg.org/#dom-mutationrecord-target target] set to ''target''.
2) If ''name'' and ''namespace'' are given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributename attributeName] to ''name'', and ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributenamespace attributeNamespace] to ''namespace''.
3) If ''addedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-addednodes addedNodes] to ''addedNodes''.
4) If ''removedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-removednodes removedNodes] to ''removedNodes'',
5) If ''previousSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-previoussibling previousSibling] to ''previousSibling''.
6) If ''nextSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-nextsibling nextSibling] to ''nextSibling''.
7) If ''observer'' has a paired string, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-oldvalue oldValue] to ''observer''’s paired string.
8) Then, append ''record'' to ''observer''’s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
5) [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask Queue a mutation observer compound microtask].

*We will make [https://dom.spec.whatwg.org/#concept-element-attributes-change changing]/[https://dom.spec.whatwg.org/#concept-element-attributes-append appending]/[https://dom.spec.whatwg.org/#concept-element-attributes-remove removing]/[https://dom.spec.whatwg.org/#concept-element-attributes-replace replacing] of an attribute, queue a mutation record via the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/attr.rs#171 Attr::set_value], [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#955 Element::push_attribute], and [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#1077 Element::remove_first_matching_attribute] attributes. These changes are performed in the following steps:
**If we want to '''change''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an [https://dom.spec.whatwg.org/#concept-element element] ''element'' to value, we run these steps:
1) [https://dom.spec.whatwg.org/#queue-a-mutation-record Queue a mutation record] of "attributes" for element with name attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], namespace attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace], and oldValue
attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value].
2) If ''element'' is [https://dom.spec.whatwg.org/#concept-element-custom custom], we [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with ''element'', callback name "''attributeChangedCallback''", and an
argument list containing ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], value, and ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
3) We then run the[https://dom.spec.whatwg.org/#concept-element-attributes-change-ext attribute change steps] with ''element'', ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], ''value'', and ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
4) We set ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value] to ''value''.

**If we want to '''append''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' to an [https://dom.spec.whatwg.org/#concept-element element] ''element'', we run these steps:
1) We[https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record] of "''attributes''" for ''element'' with name ''attribute''’s[https://dom.spec.whatwg.org/#concept-attribute-local-name local name], namespace ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace], and ''oldValue''
null.
2) If ''element'' is [https://dom.spec.whatwg.org/#concept-element-custom custom], we [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with ''element'', callback name "''attributeChangedCallback''", and an
argument list containing ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], null, ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
3) We then run the attribute change steps with element, attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], null, attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and attribute’s namespace.
4) We also [https://infra.spec.whatwg.org/#list-append append] ''attribute'' to ''element''’s [https://dom.spec.whatwg.org/#concept-element-attribute attribute list].
5) We then set ''attribute''’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to ''element''.

**If we want to '''remove''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an [https://dom.spec.whatwg.org/#concept-element element] ''element'', we run these steps:
1) We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace], and oldValue
attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value].
2) If element is [https://dom.spec.whatwg.org/#concept-element-custom custom], we then [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with element, callback name "attributeChangedCallback", and an
argument list containing attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value], null, and attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
3) We run the attribute change steps with element, attribute’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], attribute’s [https://dom.spec.whatwg.org/#concept-attribute-value value], null, and attribute’s [https://dom.spec.whatwg.org/#concept-attribute-namespace namespace].
4) We then remove attribute from element’s attribute list.
5) We set attribute’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to null.

**If we want to '''replace''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''oldAttr'' by an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''newAttr'' in an [https://dom.spec.whatwg.org/#concept-element element] ''element'', run these steps:
1) We[https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record] of "''attributes''" for ''element'' with name ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name],[https://dom.spec.whatwg.org/#concept-attribute-namespace namespace] ''oldAttr''’s namespace, and oldValue
''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value].
2) If element is [https://dom.spec.whatwg.org/#concept-element-custom custom], we then [https://html.spec.whatwg.org/multipage/scripting.html#enqueue-a-custom-element-callback-reaction enqueue a custom element callback reaction] with element, callback name "attributeChangedCallback", and an
argument list containing ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], ''newAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and ''oldAttr''’s namespace.
3) We run the attribute change steps with element, ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-local-name local name], ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], ''newAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-value value], and ''oldAttr''’s namespace.
4) We then [https://infra.spec.whatwg.org/#list-replace replace] ''oldAttr'' by ''newAttr'' in element’s [https://dom.spec.whatwg.org/#concept-element-attribute attribute list].
5) We set ''oldAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to null.
6) We set ''newAttr''’s [https://dom.spec.whatwg.org/#concept-attribute-element element] to ''element''.

=='''Test Plan'''==
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project],, our tests were written with regard to attributes, Childlist, Character data and records of a Mutation Observer. These tests are present in web-platform-tests directory (i.e <code>.tests/wpt/web-platform-tests/dom/nodes</code>).

The project owner from Mozilla has [https://github.com/servo/servo/issues/6633#issuecomment-292680210 mentioned] that the existing tests will provide enough coverage for the newly added code as well. Furthermore, it was advised to create simple tests using the following steps:

1) The simplest way to create a new test is to use the following command: ./mach create-wpt tests/wpt/path/to/new/test.html.
2) This will create test.html in the appropriate directory using the WPT template for JavaScript tests. Tests are written using testharness.js.
3) To create a new reference test instead, use the following: ./mach create-wpt --reftest tests/wpt/path/to/new/reftest.html --reference tests/wpt/path/to/reference.html
4) reference.html will be created if it does not exist, and reftest.html will be created using the WPT reftest template.
5) These new tests can then be run in the following manner like any other WPT test: ./mach test-wpt tests/wpt/path/to/new/test.html and
./mach test-wpt tests/wpt/path/to/new/reftest.html

For this part of the project, our test plan is to check the following:
*Test the micro task for mutation observer.
**Check if microtask queued flag is initially unset.
**Check if the task returns on setting the microtask queued flag.
**On notifying mutation observers, check if microtask queued flag is unset.
**Check the size of record queue on notifying mutation observers.
**Check if the number of events fired is equal to number of slots in Signal list.

*Test the observation of specific mutations:
**Whenever an observe method is invoked and attributeOldValue or attributeFilter is present and attributes is omitted, check if attributes is set to true.
**Whenever an observe method is invoked and characterDataOldValue is present and characterData is omitted, check if characterData is set to true.
**Whenever an observe method is invoked and a TypeError is thrown, check if atleast one of the following scenarios are true.
***If none of options’ childList, attributes, and characterData is true.
***attributeOldValue is true and attributes is false.
***attributeFilter is present and attributes is false.
***characterDataOldValue is true and characterData is false.

The web-platform tests can be run by giving the following command at the root directory of the project:
./mach test-wpt tests/wpt/web-platform-tests/dom/nodes.
We have Updated the corresponding test expectations as per the given [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations guidelines] in the <code>tests/wpt/metadata/dom/nodes/</code> directory.

=='''Design Pattern'''==
Our Project follows the [https://en.wikipedia.org/wiki/Observer_pattern Observer Pattern], where a list of the objects dependent on the current object is maintained and the dependents are notified of any state changes. The Mutation Observer helps in achieving this functionality.

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo 
5. https://github.com/servo/servo/wiki/Mutation-observer-project 
6. https://dom.spec.whatwg.org/

CSC/ECE 517 Spring 2017

2017-04-08T05:37:06Z

Ssrivas8: added link for M1702

==Final Project Design Document==
*[[CSC/ECE 517 Spring 2017 E1733 Text metrics]]
*[[CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design]]

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-08T00:33:07Z

Ssrivas8: /* Add support for observing specific mutations */

''' Mutation Observer API Project with SERVO & RUST '''

[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is a prototype web browser engine written in the [http://en.wikipedia.org/wiki/JavaScript RUST] language. The [https://en.wikipedia.org/wiki/Document_Object_Model DOM] standard defines a MutationObserver API that allows web content to receive callbacks when the page contents are mutated. In simple words, MutationObserver facilitates the developers with a technique to react to the changes in DOM. MutationObserver is designed to replace the Mutation Events defined in the DOM3 Events specification. The goal of this project is to implement the fundamental pieces required to support the Mutation Observer API.

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source web browser engine designed for application and embedded use. It is a high performance browser engine created by Mozilla Research and is written in the Rust language. The main idea behind the Servo is to create a parallel environment where the components are handle by isolated and fine grained tasks. These components can be rendering, HTML parsing etc.

===Rust===
[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Setting up and Building the Project'''==
Follow the Guidelines mentioned in the [https://github.com/srivassumit/servo/wiki/Readme read me] page of the project's Wiki Page for building the Project in a Linux Environment.

=='''Project Description'''==
The purpose of this project is to implement the basic functionality required to implement a [https://dom.spec.whatwg.org/#mutation-observers Mutation Observer API] as defined in the [https://dom.spec.whatwg.org DOM] Specifications.
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project], we implemented the initial Steps as described in the [https://github.com/servo/servo/wiki/Mutation-observer-project Project Specification]. The initial implementation is merged in the original Servo Repository and the code can be found [https://github.com/servo/servo/commit/107ac9ab56c1a4cee3e5f9828f91ab394e3e8eee here].
For the next phase of the project, we have to implement the functionality for supporting Mutation Observers.
Based on the Project description, we have made a Project Design, which is described in detail below.

=='''Project Design'''==

===Add support for mutation observer microtasks===

*We will add a <code>mutation_observer_compound_microtask_queued</code> member to the <code>ScriptThread</code> class. This will be used later to implement the algorithm for ''queuing a mutation observer compound microtask'' and ''notifying a mutation observer'' as described below.

*Then, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask queue a mutation observer compound microtask algorithm] by adding a new variant to the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/microtask.rs#29 Microtask] enum for mutation observers. The algorithm for doing that is described below:
1) If the ''mutation observer compound microtask queued'' flag is set, then return.
2) Set the ''mutation observer compound microtask queued'' flag.
3) [https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask Queue] a [https://html.spec.whatwg.org/multipage/webappapis.html#compound-microtask compound microtask] which will be used to notify the mutation observers.

*Next, we will implement the [https://dom.spec.whatwg.org/#notify-mutation-observers notify mutation observers algorithm] using the vector of observers previously added to the <code>ScriptThread</code> class. The notify mutation observers algorithm is implemented as described below:
1) Unset the ''mutation observer compound microtask queued'' flag, which was set in the previous algorithm.
2) Declare ''notifyList'' to be a copy of ''unit of related similar-origin browsing contexts''' list of MutationObserver objects.
3) Declare ''signalList'' to be a copy of ''unit of related similar-origin browsing contexts''' [https://dom.spec.whatwg.org/#signal-slot-list signal slot list].
4) Empty the ''unit of related similar-origin browsing contexts''' signal slot list.
5) For each MutationObserver object ''mo'' in ''notifyList'', we shall execute a ''compound microtask subtask'' to run these steps:
1) Declare ''queue'' to contain ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
2) Empty ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
3) All transient registered observers whose observer is ''mo'' will be removed.
4) If ''queue'' is non-empty, then invoke ''mo''’s callback with a list of arguments consisting of <code>queue</code> and ''mo'', and ''mo'' as the [https://heycam.github.io/webidl/#dfn-callback-this-value callback this value].
If this throws an exception, then we will report the exception.
6) For each ''[https://dom.spec.whatwg.org/#concept-slot slot]'' in ''signalList'', an event named ''slotchange'' will be fired in the same order as it is stored in the <code>signalist</code>,
with its ''[https://dom.spec.whatwg.org/#dom-event-bubbles bubbles]'' attribute set to ''true'', at ''slot''.

===Add support for observing specific mutations===
*Firstly we will add a vector of <code>MutationObserver</code> objects to <code>Node</code> to store the Mutation Observers.
*Then we will implement the [https://dom.spec.whatwg.org/#dom-mutationobserver-observe observe] method of MutationObserver. As per the DOM specification, the observe method has the following behaviour:
1) If either ''options''’ ''attributeOldValue'' or ''attributeFilter'' is present and ''options''’ ''attributes'' is omitted, then we set the ''options''’ ''attributes''
to true.
2) If options’ ''characterDataOldValue'' is present and options’ ''characterData'' is omitted, then we set options’ ''characterData'' to true.
3) If none of options’ ''childList'', attributes, and ''characterData'' is true, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
4) If options’ ''attributeOldValue'' is true and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
5) If options’ ''attributeFilter'' is present and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
6) If options’ ''characterDataOldValue'' is true and options’ ''characterData'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
7) For each [https://dom.spec.whatwg.org/#registered-observer registered observers] "''registered''" in target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] whose '''observer''' is the context object we perform the
following steps:
1) We remove all [https://dom.spec.whatwg.org/#transient-registered-observer transient registered observers] whose '''source''' is "''registered''".
2) We also replace ''registered''’s '''options''' with options.
8) Otherwise, we add a new [https://dom.spec.whatwg.org/#registered-observer registered observers] to target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] with the [https://dom.spec.whatwg.org/#context-object context object] as the observer and ''options''
as the options, and then also, we add target to [https://dom.spec.whatwg.org/#context-object context object]’s list of [https://dom.spec.whatwg.org/#concept-node node] on which it is registered.
'''Note''': Steps 7 and 8 in the above description means that we replace an existing matching entry with the new options, or add a new entry if there is no match.

*Next, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record algorithm]. Which is described as follows:
1) Declare the ''interested'' observers initially as an empty set of [https://dom.spec.whatwg.org/#mutationobserver MutationObserver] objects optionally paired with a string.
2) Declare ''nodes'' be the [https://dom.spec.whatwg.org/#concept-tree-inclusive-ancestor inclusive ancestors] of target.
3) For each ''node'' in nodes, and then for each ''registered observer'' (with ''registered observer''’s '''options''' as ''options'') in node’s list of
[https://dom.spec.whatwg.org/#registered-observer registered observers] we decide:
1) If none of the following are true
* ''node'' is not target and ''options''’ subtree is false
* ''type'' is "''attributes''" and ''options''’ ''attributes'' is not true
* ''type'' is "''attributes''", ''options''’ ''attributeFilter'' is present, and ''options''’ ''attributeFilter'' does not contain name or namespace is non-null
* ''type'' is "''characterData''" and ''options''’ ''characterData'' is not true
* ''type'' is "''childList''" and ''options''’ ''childList'' is false
then,:
1) If ''registered observer''’s '''observer''' is not in ''interested'' observers, we append ''registered observer''’s '''observer''' to ''interested observers''.
2) If either type is "''attributes''" and ''options''’ ''attributeOldValue'' is true, or type is "''characterData''" and ''options''’
''characterDataOldValue'' is true,we set the paired string of ''registered observer''’s '''observer''' in ''interested observers'' to ''oldValue''.
4) For each ''observer'' in ''interested observers'':
1) Declare ''record'' to be a new [https://dom.spec.whatwg.org/#mutationrecord MutationRecord] object with its [https://dom.spec.whatwg.org/#dom-mutationrecord-type type] set to ''type'' and [https://dom.spec.whatwg.org/#dom-mutationrecord-target target] set to ''target''.
2) If ''name'' and ''namespace'' are given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributename attributeName] to ''name'', and ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributenamespace attributeNamespace] to ''namespace''.
3) If ''addedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-addednodes addedNodes] to ''addedNodes''.
4) If ''removedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-removednodes removedNodes] to ''removedNodes'',
5) If ''previousSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-previoussibling previousSibling] to ''previousSibling''.
6) If ''nextSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-nextsibling nextSibling] to ''nextSibling''.
7) If ''observer'' has a paired string, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-oldvalue oldValue] to ''observer''’s paired string.
8) Then, append ''record'' to ''observer''’s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
5) [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask Queue a mutation observer compound microtask].

*We will make [https://dom.spec.whatwg.org/#concept-element-attributes-change changing]/[https://dom.spec.whatwg.org/#concept-element-attributes-append appending]/[https://dom.spec.whatwg.org/#concept-element-attributes-remove removing]/[https://dom.spec.whatwg.org/#concept-element-attributes-replace replacing] of an attribute, queue a mutation record via the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/attr.rs#171 Attr::set_value], [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#955 Element::push_attribute], and [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#1077 Element::remove_first_matching_attribute] attributes. These changes are performed in the following steps:
**If we want to '''change''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an [https://dom.spec.whatwg.org/#concept-element element] ''element'' to value, we run these steps:
* Queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.
* If element is custom, we enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, attribute’s value, value, and attribute’s namespace.
* We then run the attribute change steps with element, attribute’s local name, attribute’s value, value, and attribute’s namespace.
* We set attribute’s value to value.
**If we want to '''append''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' to an [https://dom.spec.whatwg.org/#concept-element element] ''element'', we run these steps:
* We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue null.
* If element is custom, we enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, null, attribute’s value, and attribute’s namespace.
* We then run the attribute change steps with element, attribute’s local name, null, attribute’s value, and attribute’s namespace.
* We also append attribute to element’s attribute list.
* We then set attribute’s element to element.
**If we want to '''remove''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an [https://dom.spec.whatwg.org/#concept-element element] ''element'', we run these steps:
* We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.
* If element is custom, we then enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, attribute’s value, null, and attribute’s namespace.
* We run the attribute change steps with element, attribute’s local name, attribute’s value, null, and attribute’s namespace.
* We then remove attribute from element’s attribute list.
* We set attribute’s element to null.
**If we want to '''replace''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''oldAttr'' by an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''newAttr'' in an [https://dom.spec.whatwg.org/#concept-element element] ''element'', run these steps:
* We queue a mutation record of "attributes" for element with name oldAttr’s local name, namespace oldAttr’s namespace, and oldValue oldAttr’s value.
* If element is custom, we then enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing oldAttr’s local name, oldAttr’s value, newAttr’s value, and oldAttr’s namespace.
* We run the attribute change steps with element, oldAttr’s local name, oldAttr’s value, newAttr’s value, and oldAttr’s namespace.
* We then replace oldAttr by newAttr in element’s attribute list.
* We set oldAttr’s element to null.
* We set newAttr’s element to element.

=='''Test Plan'''==
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project],, our tests were written with regard to attributes, Childlist, Character data and records of a Mutation Observer. These tests are present in web-platform-tests directory (i.e <code>.tests/wpt/web-platform-tests/dom/nodes</code>).

For this part of the project, our test plan is to check the following:
*Test the micro task for mutation observer.
**Check if microtask queued flag is initially unset.
**Check if the task returns on setting the microtask queued flag.
**On notifying mutation observers, check if microtask queued flag is unset.
**Check the size of record queue on notifying mutation observers.
**Check if the number of events fired is equal to number of slots in Signal list.

*Test the observation of specific mutations:
**Whenever an observe method is invoked and attributeOldValue or attributeFilter is present and attributes is omitted, check if attributes is set to true.
**Whenever an observe method is invoked and characterDataOldValue is present and characterData is omitted, check if characterData is set to true.
**Whenever an observe method is invoked and a TypeError is thrown, check if atleast one of the following scenarios are true.
***If none of options’ childList, attributes, and characterData is true.
***attributeOldValue is true and attributes is false.
***attributeFilter is present and attributes is false.
***characterDataOldValue is true and characterData is false.

The web-platform tests can be run by giving the following command at the root directory of the project:
./mach test-wpt tests/wpt/web-platform-tests/dom/nodes.
We have Updated the corresponding test expectations as per the given [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations guidelines] in the <code>tests/wpt/metadata/dom/nodes/</code> directory.

=='''Design Pattern'''==
Our Project follows the [https://en.wikipedia.org/wiki/Observer_pattern Observer Pattern], where a list of the objects dependent on the current object is maintained and the dependents are notified of any state changes. The Mutation Observer helps in achieving this functionality.

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo 
5. https://github.com/servo/servo/wiki/Mutation-observer-project 
6. https://dom.spec.whatwg.org/

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-08T00:30:23Z

Ssrivas8: /* Add support for observing specific mutations */

''' Mutation Observer API Project with SERVO & RUST '''

[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is a prototype web browser engine written in the [http://en.wikipedia.org/wiki/JavaScript RUST] language. The [https://en.wikipedia.org/wiki/Document_Object_Model DOM] standard defines a MutationObserver API that allows web content to receive callbacks when the page contents are mutated. In simple words, MutationObserver facilitates the developers with a technique to react to the changes in DOM. MutationObserver is designed to replace the Mutation Events defined in the DOM3 Events specification. The goal of this project is to implement the fundamental pieces required to support the Mutation Observer API.

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source web browser engine designed for application and embedded use. It is a high performance browser engine created by Mozilla Research and is written in the Rust language. The main idea behind the Servo is to create a parallel environment where the components are handle by isolated and fine grained tasks. These components can be rendering, HTML parsing etc.

===Rust===
[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Setting up and Building the Project'''==
Follow the Guidelines mentioned in the [https://github.com/srivassumit/servo/wiki/Readme read me] page of the project's Wiki Page for building the Project in a Linux Environment.

=='''Project Description'''==
The purpose of this project is to implement the basic functionality required to implement a [https://dom.spec.whatwg.org/#mutation-observers Mutation Observer API] as defined in the [https://dom.spec.whatwg.org DOM] Specifications.
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project], we implemented the initial Steps as described in the [https://github.com/servo/servo/wiki/Mutation-observer-project Project Specification]. The initial implementation is merged in the original Servo Repository and the code can be found [https://github.com/servo/servo/commit/107ac9ab56c1a4cee3e5f9828f91ab394e3e8eee here].
For the next phase of the project, we have to implement the functionality for supporting Mutation Observers.
Based on the Project description, we have made a Project Design, which is described in detail below.

=='''Project Design'''==

===Add support for mutation observer microtasks===

*We will add a <code>mutation_observer_compound_microtask_queued</code> member to the <code>ScriptThread</code> class. This will be used later to implement the algorithm for ''queuing a mutation observer compound microtask'' and ''notifying a mutation observer'' as described below.

*Then, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask queue a mutation observer compound microtask algorithm] by adding a new variant to the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/microtask.rs#29 Microtask] enum for mutation observers. The algorithm for doing that is described below:
1) If the ''mutation observer compound microtask queued'' flag is set, then return.
2) Set the ''mutation observer compound microtask queued'' flag.
3) [https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask Queue] a [https://html.spec.whatwg.org/multipage/webappapis.html#compound-microtask compound microtask] which will be used to notify the mutation observers.

*Next, we will implement the [https://dom.spec.whatwg.org/#notify-mutation-observers notify mutation observers algorithm] using the vector of observers previously added to the <code>ScriptThread</code> class. The notify mutation observers algorithm is implemented as described below:
1) Unset the ''mutation observer compound microtask queued'' flag, which was set in the previous algorithm.
2) Declare ''notifyList'' to be a copy of ''unit of related similar-origin browsing contexts''' list of MutationObserver objects.
3) Declare ''signalList'' to be a copy of ''unit of related similar-origin browsing contexts''' [https://dom.spec.whatwg.org/#signal-slot-list signal slot list].
4) Empty the ''unit of related similar-origin browsing contexts''' signal slot list.
5) For each MutationObserver object ''mo'' in ''notifyList'', we shall execute a ''compound microtask subtask'' to run these steps:
1) Declare ''queue'' to contain ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
2) Empty ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
3) All transient registered observers whose observer is ''mo'' will be removed.
4) If ''queue'' is non-empty, then invoke ''mo''’s callback with a list of arguments consisting of <code>queue</code> and ''mo'', and ''mo'' as the [https://heycam.github.io/webidl/#dfn-callback-this-value callback this value].
If this throws an exception, then we will report the exception.
6) For each ''[https://dom.spec.whatwg.org/#concept-slot slot]'' in ''signalList'', an event named ''slotchange'' will be fired in the same order as it is stored in the <code>signalist</code>,
with its ''[https://dom.spec.whatwg.org/#dom-event-bubbles bubbles]'' attribute set to ''true'', at ''slot''.

===Add support for observing specific mutations===
*Firstly we will add a vector of <code>MutationObserver</code> objects to <code>Node</code> to store the Mutation Observers.
*Then we will implement the [https://dom.spec.whatwg.org/#dom-mutationobserver-observe observe] method of MutationObserver. As per the DOM specification, the observe method has the following behaviour:
1) If either ''options''’ ''attributeOldValue'' or ''attributeFilter'' is present and ''options''’ ''attributes'' is omitted, then we set the ''options''’ ''attributes''
to true.
2) If options’ ''characterDataOldValue'' is present and options’ ''characterData'' is omitted, then we set options’ ''characterData'' to true.
3) If none of options’ ''childList'', attributes, and ''characterData'' is true, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
4) If options’ ''attributeOldValue'' is true and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
5) If options’ ''attributeFilter'' is present and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
6) If options’ ''characterDataOldValue'' is true and options’ ''characterData'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
7) For each [https://dom.spec.whatwg.org/#registered-observer registered observers] "''registered''" in target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] whose '''observer''' is the context object we perform the
following steps:
1) We remove all [https://dom.spec.whatwg.org/#transient-registered-observer transient registered observers] whose '''source''' is "''registered''".
2) We also replace ''registered''’s '''options''' with options.
8) Otherwise, we add a new [https://dom.spec.whatwg.org/#registered-observer registered observers] to target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] with the [https://dom.spec.whatwg.org/#context-object context object] as the observer and ''options''
as the options, and then also, we add target to [https://dom.spec.whatwg.org/#context-object context object]’s list of [https://dom.spec.whatwg.org/#concept-node node] on which it is registered.
'''Note''': Steps 7 and 8 in the above description means that we replace an existing matching entry with the new options, or add a new entry if there is no match.

*Next, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record algorithm]. Which is described as follows:
1) Declare the ''interested'' observers initially as an empty set of [https://dom.spec.whatwg.org/#mutationobserver MutationObserver] objects optionally paired with a string.
2) Declare ''nodes'' be the [https://dom.spec.whatwg.org/#concept-tree-inclusive-ancestor inclusive ancestors] of target.
3) For each ''node'' in nodes, and then for each ''registered observer'' (with ''registered observer''’s '''options''' as ''options'') in node’s list of
[https://dom.spec.whatwg.org/#registered-observer registered observers] we decide:
1) If none of the following are true
* ''node'' is not target and ''options''’ subtree is false
* ''type'' is "''attributes''" and ''options''’ ''attributes'' is not true
* ''type'' is "''attributes''", ''options''’ ''attributeFilter'' is present, and ''options''’ ''attributeFilter'' does not contain name or namespace is non-null
* ''type'' is "''characterData''" and ''options''’ ''characterData'' is not true
* ''type'' is "''childList''" and ''options''’ ''childList'' is false
then,:
1) If ''registered observer''’s '''observer''' is not in ''interested'' observers, we append ''registered observer''’s '''observer''' to ''interested observers''.
2) If either type is "''attributes''" and ''options''’ ''attributeOldValue'' is true, or type is "''characterData''" and ''options''’
''characterDataOldValue'' is true,we set the paired string of ''registered observer''’s '''observer''' in ''interested observers'' to ''oldValue''.
4) For each ''observer'' in ''interested observers'':
1) Declare ''record'' to be a new [https://dom.spec.whatwg.org/#mutationrecord MutationRecord] object with its [https://dom.spec.whatwg.org/#dom-mutationrecord-type type] set to ''type'' and [https://dom.spec.whatwg.org/#dom-mutationrecord-target target] set to ''target''.
2) If ''name'' and ''namespace'' are given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributename attributeName] to ''name'', and ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributenamespace attributeNamespace] to ''namespace''.
3) If ''addedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-addednodes addedNodes] to ''addedNodes''.
4) If ''removedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-removednodes removedNodes] to ''removedNodes'',
5) If ''previousSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-previoussibling previousSibling] to ''previousSibling''.
6) If ''nextSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-nextsibling nextSibling] to ''nextSibling''.
7) If ''observer'' has a paired string, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-oldvalue oldValue] to ''observer''’s paired string.
8) Then, append ''record'' to ''observer''’s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
5) [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask Queue a mutation observer compound microtask].

*We will make [https://dom.spec.whatwg.org/#concept-element-attributes-change changing]/[https://dom.spec.whatwg.org/#concept-element-attributes-append appending]/[https://dom.spec.whatwg.org/#concept-element-attributes-remove removing]/[https://dom.spec.whatwg.org/#concept-element-attributes-replace replacing] of an attribute, queue a mutation record via the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/attr.rs#171 Attr::set_value], [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#955 Element::push_attribute], and [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#1077 Element::remove_first_matching_attribute] attributes. These changes are performed in the following steps:
**If we want to '''change''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an element ''element'' to value, we run these steps:
* Queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.
* If element is custom, we enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, attribute’s value, value, and attribute’s namespace.
* We then run the attribute change steps with element, attribute’s local name, attribute’s value, value, and attribute’s namespace.
* We set attribute’s value to value.
**If we want to '''append''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' to an element ''element'', we run these steps:
* We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue null.
* If element is custom, we enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, null, attribute’s value, and attribute’s namespace.
* We then run the attribute change steps with element, attribute’s local name, null, attribute’s value, and attribute’s namespace.
* We also append attribute to element’s attribute list.
* We then set attribute’s element to element.
**If we want to '''remove''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''attribute'' from an element ''element'', we run these steps:
* We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.
* If element is custom, we then enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, attribute’s value, null, and attribute’s namespace.
* We run the attribute change steps with element, attribute’s local name, attribute’s value, null, and attribute’s namespace.
* We then remove attribute from element’s attribute list.
* We set attribute’s element to null.
**If we want to '''replace''' an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''oldAttr'' by an [https://dom.spec.whatwg.org/#concept-attribute attribute] ''newAttr'' in an element ''element'', run these steps:
* We queue a mutation record of "attributes" for element with name oldAttr’s local name, namespace oldAttr’s namespace, and oldValue oldAttr’s value.
* If element is custom, we then enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing oldAttr’s local name, oldAttr’s value, newAttr’s value, and oldAttr’s namespace.
* We run the attribute change steps with element, oldAttr’s local name, oldAttr’s value, newAttr’s value, and oldAttr’s namespace.
* We then replace oldAttr by newAttr in element’s attribute list.
* We set oldAttr’s element to null.
* We set newAttr’s element to element.

=='''Test Plan'''==
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project],, our tests were written with regard to attributes, Childlist, Character data and records of a Mutation Observer. These tests are present in web-platform-tests directory (i.e <code>.tests/wpt/web-platform-tests/dom/nodes</code>).

For this part of the project, our test plan is to check the following:
*Test the micro task for mutation observer.
**Check if microtask queued flag is initially unset.
**Check if the task returns on setting the microtask queued flag.
**On notifying mutation observers, check if microtask queued flag is unset.
**Check the size of record queue on notifying mutation observers.
**Check if the number of events fired is equal to number of slots in Signal list.

*Test the observation of specific mutations:
**Whenever an observe method is invoked and attributeOldValue or attributeFilter is present and attributes is omitted, check if attributes is set to true.
**Whenever an observe method is invoked and characterDataOldValue is present and characterData is omitted, check if characterData is set to true.
**Whenever an observe method is invoked and a TypeError is thrown, check if atleast one of the following scenarios are true.
***If none of options’ childList, attributes, and characterData is true.
***attributeOldValue is true and attributes is false.
***attributeFilter is present and attributes is false.
***characterDataOldValue is true and characterData is false.

The web-platform tests can be run by giving the following command at the root directory of the project:
./mach test-wpt tests/wpt/web-platform-tests/dom/nodes.
We have Updated the corresponding test expectations as per the given [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations guidelines] in the <code>tests/wpt/metadata/dom/nodes/</code> directory.

=='''Design Pattern'''==
Our Project follows the [https://en.wikipedia.org/wiki/Observer_pattern Observer Pattern], where a list of the objects dependent on the current object is maintained and the dependents are notified of any state changes. The Mutation Observer helps in achieving this functionality.

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo 
5. https://github.com/servo/servo/wiki/Mutation-observer-project 
6. https://dom.spec.whatwg.org/

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-08T00:16:01Z

Ssrivas8: /* Add support for observing specific mutations */ Updated section

''' Mutation Observer API Project with SERVO & RUST '''

[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is a prototype web browser engine written in the [http://en.wikipedia.org/wiki/JavaScript RUST] language. The [https://en.wikipedia.org/wiki/Document_Object_Model DOM] standard defines a MutationObserver API that allows web content to receive callbacks when the page contents are mutated. In simple words, MutationObserver facilitates the developers with a technique to react to the changes in DOM. MutationObserver is designed to replace the Mutation Events defined in the DOM3 Events specification. The goal of this project is to implement the fundamental pieces required to support the Mutation Observer API.

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source web browser engine designed for application and embedded use. It is a high performance browser engine created by Mozilla Research and is written in the Rust language. The main idea behind the Servo is to create a parallel environment where the components are handle by isolated and fine grained tasks. These components can be rendering, HTML parsing etc.

===Rust===
[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Setting up and Building the Project'''==
Follow the Guidelines mentioned in the [https://github.com/srivassumit/servo/wiki/Readme read me] page of the project's Wiki Page for building the Project in a Linux Environment.

=='''Project Description'''==
The purpose of this project is to implement the basic functionality required to implement a [https://dom.spec.whatwg.org/#mutation-observers Mutation Observer API] as defined in the [https://dom.spec.whatwg.org DOM] Specifications.
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project], we implemented the initial Steps as described in the [https://github.com/servo/servo/wiki/Mutation-observer-project Project Specification]. The initial implementation is merged in the original Servo Repository and the code can be found [https://github.com/servo/servo/commit/107ac9ab56c1a4cee3e5f9828f91ab394e3e8eee here].
For the next phase of the project, we have to implement the functionality for supporting Mutation Observers.
Based on the Project description, we have made a Project Design, which is described in detail below.

=='''Project Design'''==

===Add support for mutation observer microtasks===

*We will add a <code>mutation_observer_compound_microtask_queued</code> member to the <code>ScriptThread</code> class. This will be used later to implement the algorithm for ''queuing a mutation observer compound microtask'' and ''notifying a mutation observer'' as described below.

*Then, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask queue a mutation observer compound microtask algorithm] by adding a new variant to the [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/microtask.rs#29 Microtask] enum for mutation observers. The algorithm for doing that is described below:
1) If the ''mutation observer compound microtask queued'' flag is set, then return.
2) Set the ''mutation observer compound microtask queued'' flag.
3) [https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask Queue] a [https://html.spec.whatwg.org/multipage/webappapis.html#compound-microtask compound microtask] which will be used to notify the mutation observers.

*Next, we will implement the [https://dom.spec.whatwg.org/#notify-mutation-observers notify mutation observers algorithm] using the vector of observers previously added to the <code>ScriptThread</code> class. The notify mutation observers algorithm is implemented as described below:
1) Unset the ''mutation observer compound microtask queued'' flag, which was set in the previous algorithm.
2) Declare ''notifyList'' to be a copy of ''unit of related similar-origin browsing contexts''' list of MutationObserver objects.
3) Declare ''signalList'' to be a copy of ''unit of related similar-origin browsing contexts''' [https://dom.spec.whatwg.org/#signal-slot-list signal slot list].
4) Empty the ''unit of related similar-origin browsing contexts''' signal slot list.
5) For each MutationObserver object ''mo'' in ''notifyList'', we shall execute a ''compound microtask subtask'' to run these steps:
1) Declare ''queue'' to contain ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
2) Empty ''mo'''s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
3) All transient registered observers whose observer is ''mo'' will be removed.
4) If ''queue'' is non-empty, then invoke ''mo''’s callback with a list of arguments consisting of <code>queue</code> and ''mo'', and ''mo'' as the [https://heycam.github.io/webidl/#dfn-callback-this-value callback this value].
If this throws an exception, then we will report the exception.
6) For each ''[https://dom.spec.whatwg.org/#concept-slot slot]'' in ''signalList'', an event named ''slotchange'' will be fired in the same order as it is stored in the <code>signalist</code>,
with its ''[https://dom.spec.whatwg.org/#dom-event-bubbles bubbles]'' attribute set to ''true'', at ''slot''.

===Add support for observing specific mutations===
*Firstly we will add a vector of <code>MutationObserver</code> objects to <code>Node</code> to store the Mutation Observers.
*Then we will implement the [https://dom.spec.whatwg.org/#dom-mutationobserver-observe observe] method of MutationObserver. As per the DOM specification, the observe method has the following behaviour:
1) If either ''options''’ ''attributeOldValue'' or ''attributeFilter'' is present and ''options''’ ''attributes'' is omitted, then we set the ''options''’ ''attributes''
to true.
2) If options’ ''characterDataOldValue'' is present and options’ ''characterData'' is omitted, then we set options’ ''characterData'' to true.
3) If none of options’ ''childList'', attributes, and ''characterData'' is true, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
4) If options’ ''attributeOldValue'' is true and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
5) If options’ ''attributeFilter'' is present and options’ ''attributes'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
6) If options’ ''characterDataOldValue'' is true and options’ ''characterData'' is false, then we [https://heycam.github.io/webidl/#dfn-throw throw] a ''TypeError''.
7) For each [https://dom.spec.whatwg.org/#registered-observer registered observers] "''registered''" in target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] whose '''observer''' is the context object we perform the
following steps:
1) We remove all [https://dom.spec.whatwg.org/#transient-registered-observer transient registered observers] whose '''source''' is "''registered''".
2) We also replace ''registered''’s '''options''' with options.
8) Otherwise, we add a new [https://dom.spec.whatwg.org/#registered-observer registered observers] to target’s list of [https://dom.spec.whatwg.org/#registered-observer registered observers] with the [https://dom.spec.whatwg.org/#context-object context object] as the observer and ''options''
as the options, and then also, we add target to [https://dom.spec.whatwg.org/#context-object context object]’s list of [https://dom.spec.whatwg.org/#concept-node node] on which it is registered.
'''Note''': Steps 7 and 8 in the above description means that we replace an existing matching entry with the new options, or add a new entry if there is no match.

*Next, we will implement the [https://dom.spec.whatwg.org/#queue-a-mutation-record queue a mutation record algorithm]. Which is described as follows:
1) Declare the ''interested'' observers initially as an empty set of [https://dom.spec.whatwg.org/#mutationobserver MutationObserver] objects optionally paired with a string.
2) Declare ''nodes'' be the [https://dom.spec.whatwg.org/#concept-tree-inclusive-ancestor inclusive ancestors] of target.
3) For each ''node'' in nodes, and then for each ''registered observer'' (with ''registered observer''’s '''options''' as ''options'') in node’s list of
[https://dom.spec.whatwg.org/#registered-observer registered observers] we decide:
1) If none of the following are true
* ''node'' is not target and ''options''’ subtree is false
* ''type'' is "''attributes''" and ''options''’ ''attributes'' is not true
* ''type'' is "''attributes''", ''options''’ ''attributeFilter'' is present, and ''options''’ ''attributeFilter'' does not contain name or namespace is non-null
* ''type'' is "''characterData''" and ''options''’ ''characterData'' is not true
* ''type'' is "''childList''" and ''options''’ ''childList'' is false
then,:
1) If ''registered observer''’s '''observer''' is not in ''interested'' observers, we append ''registered observer''’s '''observer''' to ''interested observers''.
2) If either type is "''attributes''" and ''options''’ ''attributeOldValue'' is true, or type is "''characterData''" and ''options''’
''characterDataOldValue'' is true,we set the paired string of ''registered observer''’s '''observer''' in ''interested observers'' to ''oldValue''.
4) For each ''observer'' in ''interested observers'':
1) Declare ''record'' to be a new [https://dom.spec.whatwg.org/#mutationrecord MutationRecord] object with its [https://dom.spec.whatwg.org/#dom-mutationrecord-type type] set to ''type'' and [https://dom.spec.whatwg.org/#dom-mutationrecord-target target] set to ''target''.
2) If ''name'' and ''namespace'' are given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributename attributeName] to ''name'', and ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-attributenamespace attributeNamespace] to ''namespace''.
3) If ''addedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-addednodes addedNodes] to ''addedNodes''.
4) If ''removedNodes'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-removednodes removedNodes] to ''removedNodes'',
5) If ''previousSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-previoussibling previousSibling] to ''previousSibling''.
6) If ''nextSibling'' is given, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-nextsibling nextSibling] to ''nextSibling''.
7) If ''observer'' has a paired string, we set ''record''’s [https://dom.spec.whatwg.org/#dom-mutationrecord-oldvalue oldValue] to ''observer''’s paired string.
8) Then, append ''record'' to ''observer''’s [https://dom.spec.whatwg.org/#concept-mo-queue record queue].
5) [https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask Queue a mutation observer compound microtask].

*We will make [https://dom.spec.whatwg.org/#concept-element-attributes-change changing]/[https://dom.spec.whatwg.org/#concept-element-attributes-append appending]/[https://dom.spec.whatwg.org/#concept-element-attributes-remove removing]/[https://dom.spec.whatwg.org/#concept-element-attributes-replace replacing] an attribute queue a mutation record via [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/attr.rs#171 Attr::set_value], [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#955 Element::push_attribute], and [https://dxr.mozilla.org/servo/rev/216a89f7766dd366c4afbeae42cf6e1fb4f67349/components/script/dom/element.rs#1077 Element::remove_first_matching_attribute].
**In order to perform the following tasks, we will follow the steps given after them.
**If we want to change an attribute attribute from an element element to value, we run these steps:
***We first queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.
***If element is custom, we enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, attribute’s value, value, and attribute’s namespace.
***We then run the attribute change steps with element, attribute’s local name, attribute’s value, value, and attribute’s namespace.
***We set attribute’s value to value.
**If we want to append an attribute attribute to an element element, we run these steps:
***We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue null.
***If element is custom, we enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, null, attribute’s value, and attribute’s namespace.
***We then run the attribute change steps with element, attribute’s local name, null, attribute’s value, and attribute’s namespace.
***We also append attribute to element’s attribute list.
***We then set attribute’s element to element.
**If we want to remove an attribute attribute from an element element, we run these steps:
***We queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.
***If element is custom, we then enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing attribute’s local name, attribute’s value, null, and attribute’s namespace.
***We run the attribute change steps with element, attribute’s local name, attribute’s value, null, and attribute’s namespace.
***We then remove attribute from element’s attribute list.
***We set attribute’s element to null.
**If we want to replace an attribute oldAttr by an attribute newAttr in an element element, run these steps:
***We first queue a mutation record of "attributes" for element with name oldAttr’s local name, namespace oldAttr’s namespace, and oldValue oldAttr’s value.
***If element is custom, we then enqueue a custom element callback reaction with element, callback name "attributeChangedCallback", and an argument list containing oldAttr’s local name, oldAttr’s value, newAttr’s value, and oldAttr’s namespace.
***We run the attribute change steps with element, oldAttr’s local name, oldAttr’s value, newAttr’s value, and oldAttr’s namespace.
***We then replace oldAttr by newAttr in element’s attribute list.
***We set oldAttr’s element to null.
***We set newAttr’s element to element.

=='''Test Plan'''==
In the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2017/M1702_Implement_the_Mutation_Observer_API First Phase of the Project],, our tests were written with regard to attributes, Childlist, Character data and records of a Mutation Observer. These tests are present in web-platform-tests directory (i.e <code>.tests/wpt/web-platform-tests/dom/nodes</code>).

For this part of the project, our test plan is to check the following:
*Test the micro task for mutation observer.
**Check if microtask queued flag is initially unset.
**Check if the task returns on setting the microtask queued flag.
**On notifying mutation observers, check if microtask queued flag is unset.
**Check the size of record queue on notifying mutation observers.
**Check if the number of events fired is equal to number of slots in Signal list.

*Test the observation of specific mutations:
**Whenever an observe method is invoked and attributeOldValue or attributeFilter is present and attributes is omitted, check if attributes is set to true.
**Whenever an observe method is invoked and characterDataOldValue is present and characterData is omitted, check if characterData is set to true.
**Whenever an observe method is invoked and a TypeError is thrown, check if atleast one of the following scenarios are true.
***If none of options’ childList, attributes, and characterData is true.
***attributeOldValue is true and attributes is false.
***attributeFilter is present and attributes is false.
***characterDataOldValue is true and characterData is false.

The web-platform tests can be run by giving the following command at the root directory of the project:
./mach test-wpt tests/wpt/web-platform-tests/dom/nodes.
We have Updated the corresponding test expectations as per the given [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations guidelines] in the <code>tests/wpt/metadata/dom/nodes/</code> directory.

=='''Design Pattern'''==
Our Project follows the [https://en.wikipedia.org/wiki/Observer_pattern Observer Pattern], where a list of the objects dependent on the current object is maintained and the dependents are notified of any state changes. The Mutation Observer helps in achieving this functionality.

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo 
5. https://github.com/servo/servo/wiki/Mutation-observer-project 
6. https://dom.spec.whatwg.org/

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T23:27:39Z

Ssrivas8: /* Add support for mutation observer microtasks */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T23:25:00Z

Ssrivas8: /* Project Design */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T23:14:10Z

Ssrivas8: /* Project Design */ Updated the Project Design

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T22:38:22Z

Ssrivas8: /* Project Description */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T22:36:50Z

Ssrivas8: /* Project Description */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T22:04:28Z

Ssrivas8: /* Add support for observing specific mutations */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T22:04:05Z

Ssrivas8: /* Add support for observing specific mutations */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-07T21:31:45Z

Ssrivas8: /* Project Description */ Updated the project description

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-04-05T19:54:10Z

Ssrivas8: /* Project Description */ updated the code snippets to the latest submitted and merged version

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-05T19:34:15Z

Ssrivas8: /* Project Description */ formatted some links

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-05T19:32:22Z

Ssrivas8: /* Design Pattern */ corrected broken link

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API Design

2017-04-05T19:31:42Z

Ssrivas8: created the initial page structure and description

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-31T03:23:32Z

Ssrivas8: /* Project Description */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-31T02:53:26Z

Ssrivas8: /* Testing */ added reason for not having a separate test plan

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-31T02:49:32Z

Ssrivas8: /* Project Description */ changes as per the review comments.

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-23T21:25:04Z

Ssrivas8: /* Project Description */ correcte the mutationobserver interface

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-23T21:12:08Z

Ssrivas8: /* Project Description */ formatting

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-23T21:08:38Z

Ssrivas8: added parts for Implementation

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-23T20:31:15Z

Ssrivas8:

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-23T19:53:18Z

Ssrivas8: /* Tracking issue */

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-23T19:45:03Z

Ssrivas8: added more info.

CSC/ECE 517 Spring 2017/Implement the Mutation Observer API M1702

2017-03-22T06:10:32Z

Ssrivas8: moved CSC/ECE 517 Spring 2017/Implement the Mutation Observer API M1702 to CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API: renamed

#REDIRECT [[CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API]]

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-22T06:10:32Z

Ssrivas8: moved CSC/ECE 517 Spring 2017/Implement the Mutation Observer API M1702 to CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API: renamed

''' Mutation Observer API Project with SERVO & RUST '''

Servo is a prototype web browser engine written in the [http://en.wikipedia.org/wiki/JavaScript RUST] language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Background information'''==
The DOM standard defines a MutationObserver API that allows web content to receive callbacks when the page contents are mutated. The goal of this work is to implement the fundamental pieces required to support this API.

=='''Tracking issue'''==
The Original Tracking Issue for the same can be found at the [https://github.com/servo/servo/issues/6633 Tracking Issue] page of the [https://github.com/servo/servo/wiki/Mutation-observer-project Mutation Observer Project].

=='''Project Description'''==
*'''Initial steps''':
**create the MutationObserver and MutationRecord interfaces with stub method implementations
*** hide the new interfaces by default by adding a [Pref="dom.mutation_observer.enabled"] attribute to each one and add a corresponding preference to resources/prefs.json
**add a __dir__.ini file to tests/wpt/metadata/dom/nodes/ which enables the new preference, then run the tests in that directory and update the expected test results.
**Add a vector of MutationObserver objects as a member of ScriptThread
**Implement the MutationObserver constructor

=='''Design Patterns'''==
TODO

=='''Conclusion'''==
After making our changes,...TODO

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine)

CSC/ECE 517 Spring 2017/M1702 Implement the Mutation Observer API

2017-03-22T06:09:08Z

Ssrivas8: created the initial page structure and description