Support for gaia login.

Support for gaia login.

TODO: Add a regression test to cros repository or figure out how credentials.json
can be used for a unit test.

BUG=308757
TEST=manual
NOTRY=True

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

[achuithb, 2014-03-20 00:21:10]

Tim, please take a look.

[Tim Song, 2014-03-20 19:12:41]

Will there be support to setup a fake GAIA server to exercise this flow in unit
tests?

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
File tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
(right):

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:219: elif
self.browser_options.gaia_login:
What happens if the user is already added from a previous GAIA login? Shouldn't
we delete that user before attempting to go through the flow?

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:320:
oobe.ExecuteJavaScript("chrome.send('addUser');")
This will be called for every single polling iteration during the util.WaitFor.
Shouldn't we only call it once?

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:321: for
gaia_context in range(15):
Why 15? I thought we only have one iframe for the GAIA signin. Shouldn't the
context id be fixed?

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:336: def
_NavigateGaiaLogin(self):
Please add a comment explaining the difference between _NavigateGaiaLogin and
_NavigateLogin.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:348:
self._WaitForLogin()
This won't handle 2FA, but I'm guessing that is a bit out of scope for the
tests.

[achuithb, 2014-03-20 19:34:19]

I'll open a bug for creating a fake gaia service for the unit test. I suspect
Nikita may already have one for his browser tests - I'll ask.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
File tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
(right):

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:219: elif
self.browser_options.gaia_login:
On 2014/03/20 19:12:42, Tim Song wrote:
> What happens if the user is already added from a previous GAIA login?
Shouldn't
> we delete that user before attempting to go through the flow?

No, this is still ok - you can click add user and relogin and the right thing
happens.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:320:
oobe.ExecuteJavaScript("chrome.send('addUser');")
On 2014/03/20 19:12:42, Tim Song wrote:
> This will be called for every single polling iteration during the
util.WaitFor.
> Shouldn't we only call it once?

So the problem is that the first invocation of chrome send just vanishes and has
no effect - I imagine this is because the bindings are not active yet. So the
first time around, we don't end up on the addUser page, and this function
returns None. It works the second time around.

I tried calling _WaitForOobeReady (which ensures that the Oobe.loginForTesting
variable is ready), as well as _WaitForSigninScreen, but neither of these ensure
that chrome.send is ready. When we switch to using an api similar to
loginForTesting, this problem should go away.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:321: for
gaia_context in range(15):
On 2014/03/20 19:12:42, Tim Song wrote:
> Why 15? I thought we only have one iframe for the GAIA signin. Shouldn't the
> context id be fixed?

It has been context 6 in my testing. There are something like 14 contexts. I'd
rather search for the right context rather than hardcode it so this is a bit
more robust.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:336: def
_NavigateGaiaLogin(self):
On 2014/03/20 19:12:42, Tim Song wrote:
> Please add a comment explaining the difference between _NavigateGaiaLogin and
> _NavigateLogin.

Done.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:348:
self._WaitForLogin()
On 2014/03/20 19:12:42, Tim Song wrote:
> This won't handle 2FA, but I'm guessing that is a bit out of scope for the
> tests.

Right, it is.

[Tim Song, 2014-03-20 22:55:19]

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
File tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
(right):

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:320:
oobe.ExecuteJavaScript("chrome.send('addUser');")
On 2014/03/20 19:34:19, achuith.bhandarkar wrote:
> On 2014/03/20 19:12:42, Tim Song wrote:
> > This will be called for every single polling iteration during the
> util.WaitFor.
> > Shouldn't we only call it once?
> 
> So the problem is that the first invocation of chrome send just vanishes and
has
> no effect - I imagine this is because the bindings are not active yet. So the
> first time around, we don't end up on the addUser page, and this function
> returns None. It works the second time around.
> 
> I tried calling _WaitForOobeReady (which ensures that the Oobe.loginForTesting
> variable is ready), as well as _WaitForSigninScreen, but neither of these
ensure
> that chrome.send is ready. When we switch to using an api similar to
> loginForTesting, this problem should go away.

If you're going to implement an API to bring up the GAIA sign-in page, I guess
this is okay for now.

The thing that's troubling me is that _WaitForOobeReady isn't actually waiting
until the OOBE is ready if the WebUI message handlers havn't been fully hooked
up. Even if we don't use chrome.send, a lot of things in the OOBE might
indirectly call it, and this might cause hard to debug problems. 

We should move to a proper check that returns true only after the OOBE sends the
"loginVisible" message.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:321: for
gaia_context in range(15):
On 2014/03/20 19:34:19, achuith.bhandarkar wrote:
> On 2014/03/20 19:12:42, Tim Song wrote:
> > Why 15? I thought we only have one iframe for the GAIA signin. Shouldn't the
> > context id be fixed?
> 
> It has been context 6 in my testing. There are something like 14 contexts. I'd
> rather search for the right context rather than hardcode it so this is a bit
> more robust.

Is there no functionality to query iframe information in telemetry?

[achuithb, 2014-03-20 23:43:19]

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
File tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
(right):

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:320:
oobe.ExecuteJavaScript("chrome.send('addUser');")
On 2014/03/20 22:55:19, Tim Song wrote:
> On 2014/03/20 19:34:19, achuith.bhandarkar wrote:
> > On 2014/03/20 19:12:42, Tim Song wrote:
> > > This will be called for every single polling iteration during the
> > util.WaitFor.
> > > Shouldn't we only call it once?
> > 
> > So the problem is that the first invocation of chrome send just vanishes and
> has
> > no effect - I imagine this is because the bindings are not active yet. So
the
> > first time around, we don't end up on the addUser page, and this function
> > returns None. It works the second time around.
> > 
> > I tried calling _WaitForOobeReady (which ensures that the
Oobe.loginForTesting
> > variable is ready), as well as _WaitForSigninScreen, but neither of these
> ensure
> > that chrome.send is ready. When we switch to using an api similar to
> > loginForTesting, this problem should go away.
> 
> If you're going to implement an API to bring up the GAIA sign-in page, I guess
> this is okay for now.
> 
> The thing that's troubling me is that _WaitForOobeReady isn't actually waiting
> until the OOBE is ready if the WebUI message handlers havn't been fully hooked
> up. Even if we don't use chrome.send, a lot of things in the OOBE might
> indirectly call it, and this might cause hard to debug problems. 
> 
> We should move to a proper check that returns true only after the OOBE sends
the
> "loginVisible" message.

Ah, ok - I'll take a look at when that happens; I wasn't aware of it. I'm
planning to add a bunch of telemetry test-related stuff to oobe. I'll open a bug
to track this.

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:321: for
gaia_context in range(15):
On 2014/03/20 22:55:19, Tim Song wrote:
> On 2014/03/20 19:34:19, achuith.bhandarkar wrote:
> > On 2014/03/20 19:12:42, Tim Song wrote:
> > > Why 15? I thought we only have one iframe for the GAIA signin. Shouldn't
the
> > > context id be fixed?
> > 
> > It has been context 6 in my testing. There are something like 14 contexts.
I'd
> > rather search for the right context rather than hardcode it so this is a bit
> > more robust.
> 
> Is there no functionality to query iframe information in telemetry?

No, you basically just learn that a couple of new page contexts are available
from the devtools api. The order of these contexts is also not reliable - I
think it depends on the order in which these iframes are loaded.

[Tim Song, 2014-03-21 00:43:24]

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
File tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
(right):

https://codereview.chromium.org/205763002/diff/1/tools/telemetry/telemetry/co...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:321: for
gaia_context in range(15):
On 2014/03/20 23:43:19, achuith.bhandarkar wrote:
> On 2014/03/20 22:55:19, Tim Song wrote:
> > On 2014/03/20 19:34:19, achuith.bhandarkar wrote:
> > > On 2014/03/20 19:12:42, Tim Song wrote:
> > > > Why 15? I thought we only have one iframe for the GAIA signin. Shouldn't
> the
> > > > context id be fixed?
> > > 
> > > It has been context 6 in my testing. There are something like 14 contexts.
> I'd
> > > rather search for the right context rather than hardcode it so this is a
bit
> > > more robust.
> > 
> > Is there no functionality to query iframe information in telemetry?
> 
> No, you basically just learn that a couple of new page contexts are available
> from the devtools api. The order of these contexts is also not reliable - I
> think it depends on the order in which these iframes are loaded.

Can there ever be more than 15 contexts?

[zel, 2014-03-28 22:31:44]

LGTM

let's get this in right now, CrOS badly needs this for upcoming pyautogedon

resolved the minor details in another CL

[zel, 2014-03-28 22:44:21]

https://codereview.chromium.org/205763002/diff/20001/tools/telemetry/telemetr...
File tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
(right):

https://codereview.chromium.org/205763002/diff/20001/tools/telemetry/telemetr...
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:349:
"document.getElementById('signIn').click();", gaia_context)
nit, a cheaper way to replace lines 342-349 would be:


oobe.ExecuteJavaScriptInContext(
         "function() {"+
         "  document.getElementById('Email').value='%s';"+
         "  document.getElementById('Passwd').value='%s';"+
         "  document.getElementById('signIn').click();}();" %
             (self.browser_options.username, self.browser_options.password),
         gaia_context);

[zel, 2014-03-28 22:45:45]

The CQ bit was checked by zelidrag@chromium.org

[commit-bot: I haz the power, 2014-03-28 22:49:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/205763002/20001

[commit-bot: I haz the power, 2014-03-28 22:49:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-28 22:49:14]

Failed to apply patch for
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
  Hunk #1 FAILED at 216.
  Hunk #2 FAILED at 311.
  Hunk #3 FAILED at 332.
  3 out of 3 hunks FAILED -- saving rejects to file
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py.rej

Patch:      
tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
Index: tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
diff --git
a/tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
b/tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
index
84dfe0ebe5e26812611d16e0b87225771a3d59d1..170ad343b6caa9a777199ffb1f53a71f81917d9b
100644
--- a/tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
+++ b/tools/telemetry/telemetry/core/backends/chrome/cros_browser_backend.py
@@ -216,8 +216,10 @@ class
CrOSBrowserBackend(chrome_browser_backend.ChromeBrowserBackend):
         # incognito browser in a separate process, which we need to wait for.
         util.WaitFor(lambda: pid != self.pid, 10)
         self._WaitForBrowserToComeUp()
+      elif self.browser_options.gaia_login:
+        self._NavigateGaiaLogin()
       else:
-        self._NavigateLogin()
+        self._NavigateFakeLogin()
 
     logging.info('Browser is up!')
 
@@ -311,19 +313,52 @@ class
CrOSBrowserBackend(chrome_browser_backend.ChromeBrowserBackend):
             exceptions.BrowserConnectionGoneException):
       pass
 
+  def _GaiaLoginContext(self):
+    oobe = self.oobe
+    # TODO(achuith): Implement an api in the oobe instead of calling
+    # chrome.send.
+    oobe.ExecuteJavaScript("chrome.send('addUser');")
+    for gaia_context in range(15):
+      try:
+        if oobe.EvaluateJavaScriptInContext(
+            "document.getElementById('Email') != null", gaia_context):
+          return gaia_context
+      except exceptions.EvaluateException:
+        pass
+    return None
+
   def _NavigateGuestLogin(self):
     """Navigates through oobe login screen as guest"""
-    if not self.oobe_exists:
-      raise exceptions.LoginException('Oobe missing')
     self._WaitForSigninScreen()
     self._ClickBrowseAsGuest()
     util.WaitFor(self._IsLoggedIn, 30)
 
-  def _NavigateLogin(self):
-    """Navigates through oobe login screen"""
+  def _NavigateGaiaLogin(self):
+    """Logs into the GAIA service with provided credentials."""
+    # TODO(achuith): Fake gaia service with a python server.
+    self._WaitForSigninScreen()
+    gaia_context = util.WaitFor(self._GaiaLoginContext, timeout=10)
+    oobe = self.oobe
+    oobe.ExecuteJavaScriptInContext(
+        "document.getElementById('Email').value='%s';"
+            % self.browser_options.username, gaia_context)
+    oobe.ExecuteJavaScriptInContext(
+        "document.getElementById('Passwd').value='%s';"
+            % self.browser_options.password, gaia_context)
+    oobe.ExecuteJavaScriptInContext(
+        "document.getElementById('signIn').click();", gaia_context)
+    self._WaitForLogin()
+
+  def _NavigateFakeLogin(self):
+    """Invokes Oobe.loginForTesting for a fake login to the device."""
     logging.info('Invoking Oobe.loginForTesting')
-    if not self.oobe_exists:
-      raise exceptions.LoginException('Oobe missing')
+    self._WaitForOobeReady()
+    self.oobe.ExecuteJavaScript(
+        'Oobe.loginForTesting(\'%s\', \'%s\');'
+            % (self.browser_options.username, self.browser_options.password))
+    self._WaitForLogin()
+
+  def _WaitForOobeReady(self):
     oobe = self.oobe
     util.WaitFor(lambda: oobe.EvaluateJavaScript(
         'typeof Oobe !== \'undefined\''), 10)
@@ -332,10 +367,7 @@ class
CrOSBrowserBackend(chrome_browser_backend.ChromeBrowserBackend):
         'typeof Oobe.loginForTesting == \'undefined\''):
       raise exceptions.LoginException('Oobe.loginForTesting js api missing')
 
-    oobe.ExecuteJavaScript(
-        'Oobe.loginForTesting(\'%s\', \'%s\');'
-            % (self.browser_options.username, self.browser_options.password))
-
+  def _WaitForLogin(self):
     try:
       util.WaitFor(self._IsLoggedIn, 60)
     except util.TimeoutException:

[achuithb, 2014-03-28 23:20:04]

The CQ bit was checked by achuith@chromium.org

[commit-bot: I haz the power, 2014-03-28 23:20:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/205763002/40001

[commit-bot: I haz the power, 2014-03-28 23:45:45]

Change committed as 260302