Bug 1446901 - Remove references to Valence in DevTools codebase;r=jdescottes

MozReview-Commit-ID: 86j83kKYxkV

--HG--
extra : rebase_source : cd50887d8b3cf967d4395e6a96df21f2c0466664
This commit is contained in:
Issei Horie 2018-05-05 00:52:19 +09:00
parent 2751b5cea5
commit 2193a0de05
2 changed files with 3 additions and 5 deletions

View File

@ -4,7 +4,7 @@
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).

View File

@ -16,7 +16,7 @@ This is mainly to simplify cross-platform use cases, i.e. desktop Nightly with r
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.
@ -24,7 +24,7 @@ Certainly when a new feature needs a new actor method to function, it won't work
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
@ -54,6 +54,4 @@ We used to support old Firefox OS servers (back to Gecko 28), we don't anymore.
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".