Bug 1446901 - Remove references to Valence in DevTools codebase;r=jdescottes
authorIssei Horie <is2ei.horie@gmail.com>
Sat, 05 May 2018 00:52:19 +0900
changeset 417114 fc161a91742c99542b3a66d8724a86d93d4f15b7
parent 417113 efd94fbb9f42e50716600ca2103fd737e0a4d0b5
child 417115 b19451d4e969064481b4c11857a6e505164b2d3f
push id33961
push userrgurzau@mozilla.com
push dateMon, 07 May 2018 22:08:28 +0000
treeherdermozilla-central@59005ba3cd3e [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersjdescottes
bugs1446901
milestone61.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1446901 - Remove references to Valence in DevTools codebase;r=jdescottes MozReview-Commit-ID: 86j83kKYxkV
devtools/docs/backend/actor-registration.md
devtools/docs/backend/backward-compatibility.md
--- a/devtools/docs/backend/actor-registration.md
+++ b/devtools/docs/backend/actor-registration.md
@@ -1,15 +1,15 @@
 # How to register an actor
 
 ## Tab actors vs. global actors
 
 Tab actors are the most common types of actors. That's the type of actors you will most probably be adding.
 
-Tab actors target a document, this could be a tab in Firefox or a remote document in Firefox for Android/Safari/Chrome for Android (via Valence).
+Tab actors target a document, this could be a tab in Firefox or a remote document in Firefox for Android.
 
 Global actors however are for the rest, for things not related to any particular document but instead for things global to the whole Firefox/Chrome/Safari intance the toolbox is connected to (e.g. the preference actor).
 
 ## The DebuggerServer.registerModule function
 
 To register a tab actor:
 
 ```
--- a/devtools/docs/backend/backward-compatibility.md
+++ b/devtools/docs/backend/backward-compatibility.md
@@ -11,25 +11,25 @@ In general, we should strive to maintain
 The important compatibility scenarios are:
 
 1. Nightly desktop client **MUST** maintain existing compatibility back to release channel servers.
 
 This is mainly to simplify cross-platform use cases, i.e. desktop Nightly with release Fennec.
 
 2. Servers **MAY** use traits to state a feature is not supported yet.
 
-This helps us support alternate environments like the Valence adapter, which does not implement every possible server feature.
+This helps us support alternate environments, which does not implement every possible server feature.
 
 Certainly when a new feature needs a new actor method to function, it won't work with servers that don't support it. But we should still ensure the client doesn't explode when using unrelated, existing features, at least until the above time windows have elapsed.
 
 ## Testing
 
 The harder part of this currently is that there is no automated testing to ensure the above guidelines have been met. While we hope to have this at some point, for now manual testing is needed here.
 
-The easiest way to test this is to check your work against a Firefox for Android device on release channel and Valence to ensure existing features in the area you are changing continue to function. That doesn't cover every case, but it's a great start.
+The easiest way to test this is to check your work against a Firefox for Android device on release channel to ensure existing features in the area you are changing continue to function. That doesn't cover every case, but it's a great start.
 
 ## Feature Detection
 
 Starting with Firefox 36 (thanks to [bug 1069673](https://bugzilla.mozilla.org/show_bug.cgi?id=1069673)), you can use actor feature detection to determine which actors exist and what methods they expose.
 
 1. Detecting if the server has an actor: all you need is access to the `Toolbox` instance, which all panels do, when they get instantiated. Then you can do:
 
 ```js
@@ -49,11 +49,9 @@ toolbox.target.actorHasMethod("domwalker
 The `actorHasMethod` returns a promise that resolves to a boolean.
 
 ## Removing old backward compatibility code
 
 We used to support old Firefox OS servers (back to Gecko 28), we don't anymore. Does this mean we can remove compatibility traits for it?
 
 Maybe. Keep in mind that we still want to support Firefox for Android back to release channel, so we still want to keep traits in general. That's a much smaller time window than we supported for Firefox OS, so it should allow for some simplification.
 
-A number of our traits are used by Valence as flags to tell the client "that's not implemented yet", so those are important to keep to avoid breaking this use case.
-
 The type of compatibility that could now be removed are things where the protocol semantics changed in some Gecko older than release channel and the trait is not useful for saying "I don't support feature X".