[net-internals] Remove resolved hostname from UDP_SOCKET event description.

[net-internals] Remove resolved hostname from UDP_SOCKET event description.

UDP sockets can now live across multiple HOST_RESOLVER_IMPL_JOBs, so the
hostname can no longer be used in the description.

BUG=167366
TEST=see bug


Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=174620

[szym, 2012-12-21 22:27:53]

UDP_SOCKET already logs the address in UDP_BYTES_RECEIVED (even after it's
connected), so I think just removing this code will work for now (and unbreak
net-internals).

PTAL.

[mmenke, 2012-12-21 22:49:25]

On 2012/12/21 22:27:53, szym wrote:
> UDP_SOCKET already logs the address in UDP_BYTES_RECEIVED (even after it's
> connected), so I think just removing this code will work for now (and unbreak
> net-internals).
> 
> PTAL.

LGTM.  We may want to put the code to get descriptions in a try block, just as a
protection against future regressions.

As-is, we may want to see if we can backport this to M25, mostly because of the
experiment using the built-in DNS resolver on errors.

[eroman, 2012-12-21 22:52:56]

lgtm

https://codereview.chromium.org/11663014/diff/1/chrome/browser/resources/net_...
File chrome/browser/resources/net_internals/source_entry.js (left):

https://codereview.chromium.org/11663014/diff/1/chrome/browser/resources/net_...
chrome/browser/resources/net_internals/source_entry.js:120:
this.entries_[0].params.source_dependency != undefined) {
I suspect what was missing here was a test for:
&& this.entries_[0].params

(since the rest seems to be cautious about testing for all the properties).

[szym, 2012-12-21 23:01:20]

We definitely want to merge it into M25, but right now I'm not sure if we the
consensus is that this should land as is, or:
A) instead of removing, put it in a try-catch block;
B) instead of removing, add a |&& this.entries_[0].params| test.

I tried both changes and they fix the issue. Which one do you suggest lands?

[eroman, 2012-12-21 23:14:02]

I suggest leaving it in, since it is still applicable when loading older
logs.

My preference is (B), but I will LGTM any of the three solution so far :)


On Fri, Dec 21, 2012 at 3:01 PM, <szym@chromium.org> wrote:

> We definitely want to merge it into M25, but right now I'm not sure if we
> the
> consensus is that this should land as is, or:
> A) instead of removing, put it in a try-catch block;
> B) instead of removing, add a |&& this.entries_[0].params| test.
>
> I tried both changes and they fix the issue. Which one do you suggest
> lands?
>
>
https://codereview.chromium.**org/11663014/<https://codereview.chromium.org/1...
>

[szym, 2012-12-26 16:53:54]

On 2012/12/21 23:14:02, eroman wrote:
> I suggest leaving it in, since it is still applicable when loading older
> logs.
> 
> My preference is (B), but I will LGTM any of the three solution so far :)
> 
> 
> On Fri, Dec 21, 2012 at 3:01 PM, <mailto:szym@chromium.org> wrote:
> 
> > We definitely want to merge it into M25, but right now I'm not sure if we
> > the
> > consensus is that this should land as is, or:
> > A) instead of removing, put it in a try-catch block;
> > B) instead of removing, add a |&& this.entries_[0].params| test.
> >
> > I tried both changes and they fix the issue. Which one do you suggest
> > lands?
> >
> >
>
https://codereview.chromium.**org/11663014/%3Chttps://codereview.chromium.org...>
> >

Going with (B): the extra condition.

[commit-bot: I haz the power, 2012-12-26 16:54:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/szym@chromium.org/11663014/1002

[commit-bot: I haz the power, 2012-12-26 17:50:05]

Change committed as 174620