DevTools: Use real focus in TreeOutline (issue 2644233007 by einbinder@chromium.org)

0 views
Skip to first unread message

einb...@chromium.org

unread,
Jan 20, 2017, 11:34:57 PM1/20/17
to hans....@gmail.com, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, pfel...@chromium.org, yuzo+...@chromium.org
Reviewers: hans.hillen_gmail.com
CL: https://codereview.chromium.org/2644233007/

Message:
ptal

Description:
DevTools: Use real focus in TreeOutline

BUG=none

Affected files (+65, -77 lines):
M third_party/WebKit/LayoutTests/http/tests/inspector/security/interstitial-sidebar-expected.txt
M third_party/WebKit/Source/devtools/front_end/accessibility/accessibilityNode.css
M third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js
M third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
M third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeOutline.js
M third_party/WebKit/Source/devtools/front_end/elements/elementsTreeOutline.css
M third_party/WebKit/Source/devtools/front_end/network/RequestHeadersView.js
M third_party/WebKit/Source/devtools/front_end/security/sidebar.css
M third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
M third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js


pfel...@chromium.org

unread,
Jan 20, 2017, 11:57:35 PM1/20/17
to einb...@chromium.org, hans....@gmail.com, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
File
third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
(right):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js#newcode828
third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js:828:
treeOutline.focus();
nit: why did the tree lose focus? (seems fragile)

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
(right):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css#newcode96
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css:96:
background: unset;
background is a shorthand, it should reset everything. background: none
should suffice.

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
(left):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#oldcode1008
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:1008: if
(!this.treeOutline)
I'm pretty sure this was happening :(, so removing the check is risky.

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
(right):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode138
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:138:
this.contentElement.focus();
There is no tabIndex on contentElement, is it focusable?

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode150
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:150:
element.tabIndex = -1;
element does not have tabIndex property. use setAttribute for
consistency and compilation-friendliness

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode200
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:200: if
(!this.selectedTreeElement || event.target !==
this.selectedTreeElement.listItemElement || event.shiftKey ||
listItemElement can have focusable children, if listeners don't consume
their event, you should execute it (inplace editing).

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode987
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:987:
this.treeOutline.focus();
Why going into treeOutline just to focus the node you have here?

https://codereview.chromium.org/2644233007/

pfel...@chromium.org

unread,
Jan 20, 2017, 11:58:57 PM1/20/17
to einb...@chromium.org, hans....@gmail.com, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org
General concern is around nested tree outlines - listItemElements could have
nested focusable items in which case tab traversal within the tree becomes
possible.

https://codereview.chromium.org/2644233007/

einb...@chromium.org

unread,
Jan 21, 2017, 1:20:04 AM1/21/17
to hans....@gmail.com, pfel...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org
On 2017/01/21 at 04:58:56, pfeldman wrote:
> General concern is around nested tree outlines - listItemElements could have
nested focusable items in which case tab traversal within the tree becomes
possible.

I don't see how this changes tab traversal. If you had tab stops inside the
TreeOutline, you would be able to get to them regardless of whether your initial
focus is on the TreeOutline or one of its listItemElements.

https://codereview.chromium.org/2644233007/

einb...@chromium.org

unread,
Jan 21, 2017, 1:20:32 AM1/21/17
to hans....@gmail.com, pfel...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
(right):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css#newcode96
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css:96:
background: unset;
On 2017/01/21 at 04:57:34, pfeldman wrote:
> background is a shorthand, it should reset everything. background:
none should suffice.

I copy-pasted this from the code in InspectorCommon.css. Maybe someone
had some clever reason why it was this way? It's hard to check if the
icons all look how they are supposed to.


https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
(left):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#oldcode1008
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:1008: if
(!this.treeOutline)
On 2017/01/21 at 04:57:34, pfeldman wrote:
> I'm pretty sure this was happening :(, so removing the check is risky.

I don't see how this can happen, it just calls focus. On itself. Nothing
overrides TreeOutline focus anymore.
But I agree that focusing the TreeElement directly will be less risky.


https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
(right):

https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode138
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:138:
this.contentElement.focus();
On 2017/01/21 at 04:57:34, pfeldman wrote:
> There is no tabIndex on contentElement, is it focusable?

Ah, it isn't. I think its ok for empty TreeOutlines to not be focusable.


https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode150
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:150:
element.tabIndex = -1;
On 2017/01/21 at 04:57:34, pfeldman wrote:
> element does not have tabIndex property. use setAttribute for
consistency and compilation-friendliness

Ok!


https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode200
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:200: if
(!this.selectedTreeElement || event.target !==
this.selectedTreeElement.listItemElement || event.shiftKey ||
On 2017/01/21 at 04:57:34, pfeldman wrote:
> listItemElement can have focusable children, if listeners don't
consume their event, you should execute it (inplace editing).

This was specifically to guard against that scenario. If you have an
inplace editor, we don't want left and right arrow to move you in the
treeoutline.


https://codereview.chromium.org/2644233007/diff/1/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode987
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:987:
this.treeOutline.focus();
On 2017/01/21 at 04:57:34, pfeldman wrote:
> Why going into treeOutline just to focus the node you have here?

pfel...@chromium.org

unread,
Jan 30, 2017, 1:43:07 PM1/30/17
to einb...@chromium.org, hans....@gmail.com, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js
File
third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js
(left):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js#oldcode44
third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js:44:
this.setFocusable(false);
I like it the way it was

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
File
third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
(right):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js#newcode828
third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js:828:
treeOutline.focus();
Why are we losing focus that this becomes necessary? Does navigator
inplace editing work with no need for modifications?

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
(right):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css#newcode91
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css:91:
ol.tree-outline li.selected:focus [is=ui-icon].spritesheet-smallicons {
lusha is replacing these with the use of UI.Icon all over the place.
What is happening here, why is this only added and not removed anywhere?

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
(right):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode36
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:36:
constructor(nonFocusable) {
I'd remove this and only leave the setFocusable for the API sanity.
Component would be focusable by default.

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode139
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:139: if
(this.selectedTreeElement)
What if there is no selected element? Can there be no selected element
btw? Previously we could rely upon the fact that treeoutline would pick
focus, we no longer can.

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode163
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:163:
element.listItemElement.removeAttribute('tabIndex');
It seems like you are now balancing this in the select/deselect pair?

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode1029
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:1029: if
(!this.treeOutline || this.treeOutline.selectedTreeElement !== this ||
!this.selected)
You might want to remove the tabIndex unconditionally...

https://codereview.chromium.org/2644233007/

einb...@chromium.org

unread,
Feb 1, 2017, 5:51:35 PM2/1/17
to hans....@gmail.com, pfel...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js
File
third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js
(left):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js#oldcode44
third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js:44:
this.setFocusable(false);
On 2017/01/30 at 18:43:07, pfeldman wrote:
> I like it the way it was

Done.


https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
File
third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js
(right):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js#newcode828
third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js:828:
treeOutline.focus();
On 2017/01/30 at 18:43:07, pfeldman wrote:
> Why are we losing focus that this becomes necessary? Does navigator
inplace editing work with no need for modifications?



https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css
(right):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css#newcode91
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css:91:
ol.tree-outline li.selected:focus [is=ui-icon].spritesheet-smallicons {
On 2017/01/30 at 18:43:07, pfeldman wrote:
> lusha is replacing these with the use of UI.Icon all over the place.
What is happening here, why is this only added and not removed anywhere?

I removed the focus event listener, which was adding a force-white-icons
class. Without copying over the CSS, I'd have to juggle blur and focus
event listeners on the selected TreeElements.
Edit


https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
File third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
(right):

https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode36
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:36:
constructor(nonFocusable) {
On 2017/01/30 at 18:43:07, pfeldman wrote:
> I'd remove this and only leave the setFocusable for the API sanity.
Component would be focusable by default.

Done.


https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode139
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:139: if
(this.selectedTreeElement)
On 2017/01/30 at 18:43:07, pfeldman wrote:
> What if there is no selected element? Can there be no selected element
btw? Previously we could rely upon the fact that treeoutline would pick
focus, we no longer can.

Selecting the contentElement now, and restoring focus to/from it.


https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode163
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:163:
element.listItemElement.removeAttribute('tabIndex');
On 2017/01/30 at 18:43:07, pfeldman wrote:
> It seems like you are now balancing this in the select/deselect pair?

Yep, that is better.


https://codereview.chromium.org/2644233007/diff/20001/third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js#newcode1029
third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js:1029: if
(!this.treeOutline || this.treeOutline.selectedTreeElement !== this ||
!this.selected)
On 2017/01/30 at 18:43:07, pfeldman wrote:
> You might want to remove the tabIndex unconditionally...

einb...@chromium.org

unread,
Feb 1, 2017, 5:51:38 PM2/1/17
to hans....@gmail.com, pfel...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

Pavel Feldman

unread,
Feb 1, 2017, 5:59:53 PM2/1/17
to einb...@chromium.org, hans....@gmail.com, pfel...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org
lgtm, please make sure this is in sync with Lusha's icon change.

pfel...@chromium.org

unread,
Feb 1, 2017, 8:17:30 PM2/1/17
to einb...@chromium.org, hans....@gmail.com, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

einb...@chromium.org

unread,
Feb 1, 2017, 9:54:35 PM2/1/17
to hans....@gmail.com, pfel...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org
On 2017/02/01 at 22:59:54, pfeldman wrote:
> lgtm, please make sure this is in sync with Lusha's icon change.
>
> --
> You received this message because you are subscribed to the Google Groups
"Blink Reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to blink-review...@chromium.org.
>

Done.

https://codereview.chromium.org/2644233007/

commit-bot@chromium.org via codereview.chromium.org

unread,
Feb 2, 2017, 1:20:41 AM2/2/17
to einb...@chromium.org, hans....@gmail.com, pfel...@chromium.org, commi...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

commit-bot@chromium.org via codereview.chromium.org

unread,
Feb 2, 2017, 2:32:32 AM2/2/17
to einb...@chromium.org, hans....@gmail.com, pfel...@chromium.org, commi...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org
Try jobs failed on following builders:
linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/382416)

https://codereview.chromium.org/2644233007/

commit-bot@chromium.org via codereview.chromium.org

unread,
Feb 2, 2017, 1:51:08 PM2/2/17
to einb...@chromium.org, hans....@gmail.com, pfel...@chromium.org, commi...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

commit-bot@chromium.org via codereview.chromium.org

unread,
Feb 2, 2017, 5:55:19 PM2/2/17
to einb...@chromium.org, hans....@gmail.com, pfel...@chromium.org, commi...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org

commit-bot@chromium.org via codereview.chromium.org

unread,
Feb 2, 2017, 10:25:30 PM2/2/17
to einb...@chromium.org, hans....@gmail.com, pfel...@chromium.org, commi...@chromium.org, abox...@chromium.org, aboxhal...@chromium.org, apavlo...@chromium.org, blink-...@chromium.org, caseq...@chromium.org, chromium...@chromium.org, devtools...@chromium.org, dmaz...@chromium.org, dmazzon...@chromium.org, dtseng...@chromium.org, je_jul...@chromium.org, kozyatins...@chromium.org, lushnik...@chromium.org, nek...@chromium.org, nektar...@chromium.org, pfeldma...@chromium.org, yuzo+...@chromium.org
Reply all
Reply to author
Forward
0 new messages