Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2157673002:
Browser tests for the quick_unlock settings pages. (Closed)
|
Created:
4 years, 5 months ago by jdufault Modified:
4 years, 2 months ago CC:
chromium-reviews, michaelpg+watch-md-settings_chromium.org, michaelpg+watch-md-ui_chromium.org, arv+watch_chromium.org, vitalyp+closure_chromium.org, dbeam+watch-settings_chromium.org, dbeam+watch-closure_chromium.org, stevenjb+watch-md-settings_chromium.org, jlklein+watch-closure_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@pin-unlock-quick-unlock-interface Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionBrowser tests for the quick_unlock settings pages.
BUG=627928
TBR=dbeam@
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
Committed: https://crrev.com/12d223ad3993032f0b5339187d1e6beaa86002af
Cr-Commit-Position: refs/heads/master@{#425386}
Patch Set 1 #
Total comments: 27
Patch Set 2 : Rebase #Patch Set 3 : Address comments #Patch Set 4 : Rework for new settings design #
Total comments: 1
Patch Set 5 : Rebase #
Total comments: 9
Patch Set 6 : Address comments #Messages
Total messages: 53 (32 generated)
Description was changed from ========== Browser tests for the quick_unlock settings pages. BUG=627928 ========== to ========== Browser tests for the quick_unlock settings pages. BUG=627928 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ==========
The CQ bit was checked by jdufault@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Browser tests for the quick_unlock settings pages. BUG=627928 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ========== to ========== Browser tests for the quick_unlock settings pages. BUG=627928 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ==========
jdufault@chromium.org changed reviewers: + tommycli@chromium.org
Tommy, PTAL. Thanks!
https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:122: }, 1050); Change to 50
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
Some initial comments https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... File chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js:43: * PASSWORD_ACTIVE_DURATION_MS milliseconds. nit: Update comment to say |this.passwordActiveDurationMs_|? https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js:174: this.checkAccountPassword_(this.password_, onPasswordChecked.bind(this)); Is this only called in one place? If so, why not inline it in? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/cr_settings_browsertest.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/cr_settings_browsertest.js:202: browsePreload: 'chrome://md-settings/settings_main/settings_main.html', This can't be done via preloading the quick_unlock_choose_method.html file? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/cr_settings_browsertest.js:232: browsePreload: 'chrome://md-settings/people_page/people_page.html', Same here. Can this be done by preloading setup_pin only? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:14: function assertVisible(element) { I assume it's not practical to test the .hidden property of this element? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:72: // modes. I think the test name explains it well enough so the comment isn't needed. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:97: assertTrue(!element.setModes); For symmetry with the below, can this be assertFalse(!!foo)? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:122: }, 1050); Hmm... I'm worried this test might be flaky... but I can't think of a better way to do it. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:243: setTimeout(done); This seems like it could be flaky. In other UI tests we wait for some action that occurs on the attached: handler. Maybe WebComponentsReady would be better here? http://stackoverflow.com/questions/21763690/polymer-and-webcomponentsready-event https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:325: assertDeepEquals('quick-unlock-setup-pin', does assertEquals(settings.Route.QUICK_UNLOCK_SETUP_PIN, element.currentRoute) work?
The CQ bit was checked by jdufault@chromium.org to run a CQ dry run
https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... File chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js:43: * PASSWORD_ACTIVE_DURATION_MS milliseconds. On 2016/07/18 20:47:24, tommycli wrote: > nit: Update comment to say |this.passwordActiveDurationMs_|? Done. https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js:174: this.checkAccountPassword_(this.password_, onPasswordChecked.bind(this)); On 2016/07/18 20:47:24, tommycli wrote: > Is this only called in one place? If so, why not inline it in? The way we check for account password is a bit convoluted (setting modes without actually setting them), so I found it much easier to understand by putting it behind a method. Essentially, adding the method makes the code read as if checking the account password is a single atomic operation. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/cr_settings_browsertest.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/cr_settings_browsertest.js:202: browsePreload: 'chrome://md-settings/settings_main/settings_main.html', On 2016/07/18 20:47:24, tommycli wrote: > This can't be done via preloading the quick_unlock_choose_method.html file? It can, but I'd have to put a bunch of extra unneeded dependencies on choose_method.html like the prefs/prefs.html which don't really belong there. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/cr_settings_browsertest.js:232: browsePreload: 'chrome://md-settings/people_page/people_page.html', On 2016/07/18 20:47:24, tommycli wrote: > Same here. Can this be done by preloading setup_pin only? Done. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:14: function assertVisible(element) { On 2016/07/18 20:47:24, tommycli wrote: > I assume it's not practical to test the .hidden property of this element? Right, the hidden property might have been set in a parent. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:72: // modes. On 2016/07/18 20:47:24, tommycli wrote: > I think the test name explains it well enough so the comment isn't needed. Done. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:97: assertTrue(!element.setModes); On 2016/07/18 20:47:24, tommycli wrote: > For symmetry with the below, can this be assertFalse(!!foo)? Done. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:122: }, 1050); On 2016/07/18 20:47:24, tommycli wrote: > Hmm... I'm worried this test might be flaky... but I can't think of a better way > to do it. So long as the 50 is >= all of the other setTimeout values, this should be reliable (see step 8 in https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#windowtimers). https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:243: setTimeout(done); On 2016/07/18 20:47:24, tommycli wrote: > This seems like it could be flaky. In other UI tests we wait for some action > that occurs on the attached: handler. > > Maybe WebComponentsReady would be better here? > http://stackoverflow.com/questions/21763690/polymer-and-webcomponentsready-event Changed to async, I was having troubles getting WebComponentsReady to work. Are there any examples? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:325: assertDeepEquals('quick-unlock-setup-pin', On 2016/07/18 20:47:24, tommycli wrote: > does assertEquals(settings.Route.QUICK_UNLOCK_SETUP_PIN, element.currentRoute) > work? settings.Route is undefined
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... File chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/browser/resources/se... chrome/browser/resources/settings/people_page/quick_unlock_authenticate.js:174: this.checkAccountPassword_(this.password_, onPasswordChecked.bind(this)); On 2016/07/19 00:11:07, jdufault wrote: > On 2016/07/18 20:47:24, tommycli wrote: > > Is this only called in one place? If so, why not inline it in? > > The way we check for account password is a bit convoluted (setting modes without > actually setting them), so I found it much easier to understand by putting it > behind a method. > > Essentially, adding the method makes the code read as if checking the account > password is a single atomic operation. Okay that makes sense. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:122: }, 1050); On 2016/07/19 00:11:08, jdufault wrote: > On 2016/07/18 20:47:24, tommycli wrote: > > Hmm... I'm worried this test might be flaky... but I can't think of a better > way > > to do it. > > So long as the 50 is >= all of the other setTimeout values, this should be > reliable (see step 8 in > https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#windowtimers). Can we make this not a numeric literal, but autosubmitDelayMs? And add a comment to justify it a bit? https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:243: setTimeout(done); On 2016/07/19 00:11:08, jdufault wrote: > On 2016/07/18 20:47:24, tommycli wrote: > > This seems like it could be flaky. In other UI tests we wait for some action > > that occurs on the attached: handler. > > > > Maybe WebComponentsReady would be better here? > > > http://stackoverflow.com/questions/21763690/polymer-and-webcomponentsready-event > > Changed to async, I was having troubles getting WebComponentsReady to work. Are > there any examples? See here: https://cs.chromium.org/chromium/src/chrome/test/data/webui/settings/people_p... It delays executing until the Promise returned by TestBrowserProxy.whenCalled is fulfilled. I realize you can't use this directly. Is there some other signal you could use? See https://www.polymer-project.org/1.0/docs/devguide/registering-elements#lifecy... element.async isn't the worst thing, but let's just make sure we've exhausted the other possibilities. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:325: assertDeepEquals('quick-unlock-setup-pin', On 2016/07/19 00:11:08, jdufault wrote: > On 2016/07/18 20:47:24, tommycli wrote: > > does assertEquals(settings.Route.QUICK_UNLOCK_SETUP_PIN, element.currentRoute) > > work? > > settings.Route is undefined Try importing /route.html in the quick_unlock_configure.html file?
Did Quick Unlock ever receive their browser tests? / Is there a plan to implement them?
On 2016/09/20 17:53:43, tommycli wrote: > Did Quick Unlock ever receive their browser tests? / Is there a plan to > implement them? After the m54 work is done (hopefully this week) I'm going to finish this CL.
On 2016/09/20 17:58:38, jdufault wrote: > On 2016/09/20 17:53:43, tommycli wrote: > > Did Quick Unlock ever receive their browser tests? / Is there a plan to > > implement them? > > After the m54 work is done (hopefully this week) I'm going to finish this CL. Aite cool. Thanks!
The CQ bit was checked by jdufault@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:122: }, 1050); On 2016/07/19 21:27:12, tommycli wrote: > On 2016/07/19 00:11:08, jdufault wrote: > > On 2016/07/18 20:47:24, tommycli wrote: > > > Hmm... I'm worried this test might be flaky... but I can't think of a better > > way > > > to do it. > > > > So long as the 50 is >= all of the other setTimeout values, this should be > > reliable (see step 8 in > > https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#windowtimers). > > Can we make this not a numeric literal, but autosubmitDelayMs? And add a comment > to justify it a bit? Done. https://codereview.chromium.org/2157673002/diff/1/chrome/test/data/webui/sett... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:243: setTimeout(done); On 2016/07/19 21:27:12, tommycli wrote: > On 2016/07/19 00:11:08, jdufault wrote: > > On 2016/07/18 20:47:24, tommycli wrote: > > > This seems like it could be flaky. In other UI tests we wait for some action > > > that occurs on the attached: handler. > > > > > > Maybe WebComponentsReady would be better here? > > > > > > http://stackoverflow.com/questions/21763690/polymer-and-webcomponentsready-event > > > > Changed to async, I was having troubles getting WebComponentsReady to work. > Are > > there any examples? > > See here: > https://cs.chromium.org/chromium/src/chrome/test/data/webui/settings/people_p... > > It delays executing until the Promise returned by TestBrowserProxy.whenCalled is > fulfilled. > > I realize you can't use this directly. Is there some other signal you could use? > See > https://www.polymer-project.org/1.0/docs/devguide/registering-elements#lifecy... > > element.async isn't the worst thing, but let's just make sure we've exhausted > the other possibilities. The element will now fire a 'ready' event when it is done initializing.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: ios-device on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...) ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
https://codereview.chromium.org/2157673002/diff/60001/chrome/browser/resource... File chrome/browser/resources/settings/people_page/password_prompt_dialog.js (right): https://codereview.chromium.org/2157673002/diff/60001/chrome/browser/resource... chrome/browser/resources/settings/people_page/password_prompt_dialog.js:70: //* @type {QuickUnlockPrivate} I've been having a ton of trouble getting the closure compiler to recognize QuickUnlockPrivate as a valid type (but SettingsPrivate seems to work fine - and QuickUnlockPrivate is setup the same way as SettingsPrivate as far as I can tell).
The CQ bit was checked by jdufault@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
jdufault@chromium.org changed reviewers: + dbeam@chromium.org
dbeam@ PTAL - tommycli@ is out for a few weeks. Thanks!
stevenjb@chromium.org changed reviewers: + stevenjb@chromium.org
https://codereview.chromium.org/2157673002/diff/70001/chrome/browser/resource... File chrome/browser/resources/settings/people_page/password_prompt_dialog.js (right): https://codereview.chromium.org/2157673002/diff/70001/chrome/browser/resource... chrome/browser/resources/settings/people_page/password_prompt_dialog.js:185: * @param {function(boolean):void} onCheck Since this is now a member function we don't need to pass |passwprd| or |onCheck| to it, we can just use the members directly. https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:22: } Is just testing element.offsetWidth/Height not sufficient? https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:229: //configureButton = getFromElement('#foobar');//paper-button'); ?? https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:234: //done(); ??
The CQ bit was checked by jdufault@chromium.org to run a CQ dry run
https://codereview.chromium.org/2157673002/diff/70001/chrome/browser/resource... File chrome/browser/resources/settings/people_page/password_prompt_dialog.js (right): https://codereview.chromium.org/2157673002/diff/70001/chrome/browser/resource... chrome/browser/resources/settings/people_page/password_prompt_dialog.js:185: * @param {function(boolean):void} onCheck On 2016/10/13 21:36:45, stevenjb wrote: > Since this is now a member function we don't need to pass |passwprd| or > |onCheck| to it, we can just use the members directly. |onCheck| comes from a local, but I've inlined |password|. https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... File chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js (right): https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:22: } On 2016/10/13 21:36:45, stevenjb wrote: > Is just testing element.offsetWidth/Height not sufficient? Nope :( https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:229: //configureButton = getFromElement('#foobar');//paper-button'); On 2016/10/13 21:36:45, stevenjb wrote: > ?? Done. https://codereview.chromium.org/2157673002/diff/70001/chrome/test/data/webui/... chrome/test/data/webui/settings/quick_unlock_authenticate_browsertest_chromeos.js:234: //done(); On 2016/10/13 21:36:45, stevenjb wrote: > ?? Done.
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
dbeam@chromium.org changed reviewers: - dbeam@chromium.org
stevenjb@ has the same owners rights as me for this CL and is back now, so deferring to him
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm https://codereview.chromium.org/2157673002/diff/70001/chrome/browser/resource... File chrome/browser/resources/settings/people_page/password_prompt_dialog.js (right): https://codereview.chromium.org/2157673002/diff/70001/chrome/browser/resource... chrome/browser/resources/settings/people_page/password_prompt_dialog.js:185: * @param {function(boolean):void} onCheck On 2016/10/13 23:41:23, jdufault wrote: > On 2016/10/13 21:36:45, stevenjb wrote: > > Since this is now a member function we don't need to pass |passwprd| or > > |onCheck| to it, we can just use the members directly. > > |onCheck| comes from a local, but I've inlined |password|. Oh, so it is. There doesn't seem to be much reason for that, but I guess it's fine.
The CQ bit was checked by jdufault@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
Description was changed from ========== Browser tests for the quick_unlock settings pages. BUG=627928 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ========== to ========== Browser tests for the quick_unlock settings pages. BUG=627928 TBR=dbeam@ CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ==========
TBR on dbeam@ for options_resources.grd
The CQ bit was checked by jdufault@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Browser tests for the quick_unlock settings pages. BUG=627928 TBR=dbeam@ CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ========== to ========== Browser tests for the quick_unlock settings pages. BUG=627928 TBR=dbeam@ CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ==========
Message was sent while issue was closed.
Committed patchset #6 (id:90001)
Message was sent while issue was closed.
Description was changed from ========== Browser tests for the quick_unlock settings pages. BUG=627928 TBR=dbeam@ CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation ========== to ========== Browser tests for the quick_unlock settings pages. BUG=627928 TBR=dbeam@ CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation Committed: https://crrev.com/12d223ad3993032f0b5339187d1e6beaa86002af Cr-Commit-Position: refs/heads/master@{#425386} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/12d223ad3993032f0b5339187d1e6beaa86002af Cr-Commit-Position: refs/heads/master@{#425386} |
