Support for browser aliases in DevTools.

Support for browser aliases in DevTools.

This is convenience change that allow remote target to have duplicating IDs.
This situation happen in devtool debugging environment while same browser
becomes available by several communication means. In chrome://inspect it appears
as 2 different browsers. When user inspect this target it hard to predict
which communication channel is used.

This change gives different internal IDs to targets of internal representations of
remote browsers. If user inspects 2 aliases of the same target she may be sure
that different communication channels are used.

BUG=383418

[SeRya, 2014-08-29 07:04:41]

serya@chromium.org changed reviewers:
+ vsevik@chromium.org

[SeRya, 2014-08-29 07:04:41]

While we don't officially support socket aliases DovTools work just fine with
them with this patch.

Because it is not localized in a single piece of code I feel hiding it behind
#ifdef DEVTOOLS_DEBUG caused more confusion than usefulness.

This patch is useful for me and I believe harmless for others. But if you feel
we'd better go without it I can easily live on patched chrome.

https://codereview.chromium.org/521573002/diff/1/chrome/browser/devtools/devi...
File chrome/browser/devtools/device/devtools_android_bridge.cc (left):

https://codereview.chromium.org/521573002/diff/1/chrome/browser/devtools/devi...
chrome/browser/devtools/device/devtools_android_bridge.cc:451:
debug_url_(GetDebugURL(value)),
Initialized twice.

[pfeldman, 2014-08-29 08:01:43]

pfeldman@chromium.org changed reviewers:
+ dgozman@chromium.org, pfeldman@chromium.org
- vsevik@chromium.org

[pfeldman, 2014-08-29 08:01:43]

Lets not do this. It is actually a feature to have unique ids across the
channels.

[dgozman, 2014-08-29 08:15:49]

On 2014/08/29 08:01:43, pfeldman-OOO-until-Sep-6 wrote:
> Lets not do this. It is actually a feature to have unique ids across the
> channels.
+1. Having two IDs (and perhaps two instances of DevToolsAgentHost) can mess all
the logic which implicitly assumes unique IDs.

I'm not sure the purpose of this patch is useful. Why should user care about the
channel used? We are trying to hide usb vs adb as hard as we can. Duplicate
browsers in chrome://inspect sounds like a bad UX.

[SeRya, 2014-09-01 07:57:14]

On 2014/08/29 08:15:49, dgozman wrote:
> On 2014/08/29 08:01:43, pfeldman-OOO-until-Sep-6 wrote:
> > Lets not do this. It is actually a feature to have unique ids across the
> > channels.
> +1. Having two IDs (and perhaps two instances of DevToolsAgentHost) can mess
all
> the logic which implicitly assumes unique IDs.
> 
> I'm not sure the purpose of this patch is useful. Why should user care about
the
> channel used? We are trying to hide usb vs adb as hard as we can. Duplicate
> browsers in chrome://inspect sounds like a bad UX.

This CL is not about different instances of DevToolsAgentHost. It only affects
IDs stored in DevToolsTargetsUIHandler::targets_ and therefore result of
InspectUI::FindTarget. That IDs are also propagated to Web UI.

Local IDs never leave Debugger side. There is no effect on the protocol and
debuggee side. There is no way DevToolsAgentHost may observe the difference.

So this change may no affect other users of DevTools protocol. But it may affect
any automation that relies on IDs in InspectUI.

Regarding user experience perspective you are right, this patch is only useful
if we failed to hide duplicates. We should not show duplicates to end users but
in development cycle it's useful.

I'm not completely understand what it's wrong with UI-specific IDs not equal to
external target IDs but if concerns are present I'd rather use this patch
locally.