1234693 - Point Switchboard URLs to production mozilla-services endpoint

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

In order to move into the full production system, we need to get some new URL endpoints for mozilla-switchboard.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Travis (or someone on his team) is going to get us the URLs

Comment 2

[Miles Crabill [:miles]]

The URL that I am proposing is switchboard.services.mozilla.com. Would this work for you Mark? We can freely change it if you want something that sounds cooler / more applicable. As of right now it points to the previous dev url (but doesn't work because it's a CNAME), and is using wildcard SSL certs. We will update to using a cert specific to switchboard once we confirm the URL.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Miles Crabill from comment #2)
> The URL that I am proposing is switchboard.services.mozilla.com. Would this
> work for you Mark?

Works for me. Let us know when it's working and we'll get a patch ready. The old URL will need to continue to work as well. We won't be able to switch all Firefox versions to the new URL.

Comment 4

[:Margaret Leibovic]

I can take this to write a patch. Miles shared this URL with me:

https://switchboard.services.mozilla.com/v1

Comment 5

[:Margaret Leibovic]

Attachment: MozReview Request: Bug 1234693 - Point Switchboard URLs to production mozilla-services endpoint. r=liuche

Review commit: https://reviewboard.mozilla.org/r/33761/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/33761/

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8716266 [details]
MozReview Request: Bug 1234693 - Point Switchboard URLs to production mozilla-services endpoint. r=liuche

https://reviewboard.mozilla.org/r/33761/#review30597

Comment 7

[:Margaret Leibovic]

https://hg.mozilla.org/integration/fx-team/rev/d007cfebe661581f8c70a818efa88b00e9da28af
Bug 1234693 - Point Switchboard URLs to production mozilla-services endpoint. r=mfinkle

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I backed this out in https://hg.mozilla.org/integration/fx-team/rev/3c2760822292 to see if it fixes these robocop failures: https://treeherder.mozilla.org/logviewer.html#?job_id=7146374&repo=fx-team

Could be from one of the other patches, dunno.

Comment 9

[:Margaret Leibovic]

(In reply to Wes Kocher (:KWierso) from comment #8)
> I backed this out in
> https://hg.mozilla.org/integration/fx-team/rev/3c2760822292 to see if it
> fixes these robocop failures:
> https://treeherder.mozilla.org/logviewer.html#?job_id=7146374&repo=fx-team
> 
> Could be from one of the other patches, dunno.

Sigh... there's an active switchboard experiment to change the menu items, and I'm wondering if that's interfering with this test.

I wouldn't expect us to be hitting the switchboard endpoint in automation, but I do see these in the log:

02-08 10:40:10.554  1950  1972 D SwitchBoard: Read from server URL: https://switchboard.services.mozilla.com/v1?uuid=501f8505-9b85-42b0-b717-9349e3b07ff8&device=generic&lang=eng&country=USA&manufacturer=unknown&appId=org.mozilla.fennec&version=47.0a1

02-08 10:40:43.095  1950  1972 D SwitchBoard: {"onboarding-a":{"isActive":true,"values":null},"onboarding-b":{"isActive":false,"values":null},"bookmark-history-menu":{"isActive":true,"values":null}

gbrown, I thought that the devices in automation were restricted to not do remote network activity. Am I wrong?

What's the pattern we generally follow for features that would normally hit the network (e.g. telemetry)? Should we disable this for automation?

This does raise an interesting issue about testing different experiment configurations in automation... we do want to be testing what we're releasing, and especially so in this case where we have an active experiment that's rolled out to 100% of users. So ideally we would continue to hit the switchboard server from automation, but that's also confusing because test failures might start from a configuration change on the server, as opposed to a push on treeherder, which could make tracking down failures tricky (although it would be nice to see that failure happen if it's a real failure!).

liuche landed a patch in bug 1201653 to allow us to launch the browser with a specific UUID. Maybe we should also add support for loading a local config for testing purposes? Then theoretically we could do different test runs with different configs... but that seems out of scope for right now.

Comment 10

[Geoff Brown [:gbrown]]

(In reply to :Margaret Leibovic from comment #9)
> gbrown, I thought that the devices in automation were restricted to not do
> remote network activity. Am I wrong?

You are not wrong, but...One thing to remember about MOZ_DISABLE_NONLOCAL_CONNECTIONS is that it is implemented in Necko. I think you can get away with network access in Java. Does that explain the switchboard case?
 
> What's the pattern we generally follow for features that would normally hit
> the network (e.g. telemetry)? Should we disable this for automation?

We would normally set a pref to disable or redirect. For example, http://hg.mozilla.org/mozilla-central/annotate/2dfb45d74f42/testing/profiles/prefs_general.js#l235 .

> This does raise an interesting issue about testing different experiment
> configurations in automation... we do want to be testing what we're
> releasing, and especially so in this case where we have an active experiment
> that's rolled out to 100% of users. So ideally we would continue to hit the
> switchboard server from automation, but that's also confusing because test
> failures might start from a configuration change on the server, as opposed
> to a push on treeherder, which could make tracking down failures tricky
> (although it would be nice to see that failure happen if it's a real
> failure!).

My (confused) thoughts, exactly!

Comment 11

[:Margaret Leibovic]

So, what's happening with this test failure is that the app menu is now longer with the additional bookmarks and history menus. When we open the app menu in the UITest, it is scrolled to the bottom, so the back/forward/reload buttons aren't visible and can't be clicked.

I can reproduce this locally and see what's happening.

Mike/Sebastian, I see you in blame for AppMenuComponent. Do you have any suggestions for what we could do to make sure the top of the menu is visible? Or do you know why the menu is scrolled to the bottom, since that doesn't happen when you actually tap the menu button with your finger?

Comment 12

[:Margaret Leibovic]

I should note: the problem happens with the goForward call here:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/tests/browser/robocop/src/org/mozilla/gecko/tests/testSessionHistory.java#31

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #11)
> Mike/Sebastian, I see you in blame for AppMenuComponent. Do you have any
> suggestions for what we could do to make sure the top of the menu is
> visible? Or do you know why the menu is scrolled to the bottom, since that
> doesn't happen when you actually tap the menu button with your finger?

It looks like the problem here is the waitForExactText() in findAppMenuItemView():
https://dxr.mozilla.org/mozilla-central/rev/2dfb45d74f42d2a0010696f5fd47c7a7da94cedb/mobile/android/tests/browser/robocop/src/org/mozilla/gecko/tests/components/AppMenuComponent.java#162

Robotium's waitForText() will search the text in the UI and also scroll components to find it. In this case we are looking for the text "Forward" and even with scrolling the menu we won't find it. After that we are searching the view ourselves and are not only looking for the visible text but also inside contentDescription. This also has the side effect that every time we are searching for forward/back we will always wait for 7.5s (MAX_WAITTIME_FOR_MENU_UPDATE_IN_MS) because Robotium is trying to find the text first and is failing.

The test passes after removing the line (I do not know if a different test case might require the scrolling) and it's a bit faster too.

Another option would be to not use Robotium's search and just scroll up -> search view, scroll down -> search view - assuming that the menu will never be super long. And the perfect solution probably is to implement a searchText with Robotiums tools that will look into contentDescription too.

Comment 14

[:Margaret Leibovic]

(In reply to Sebastian Kaspari (:sebastian) from comment #13)
> (In reply to :Margaret Leibovic from comment #11)
> > Mike/Sebastian, I see you in blame for AppMenuComponent. Do you have any
> > suggestions for what we could do to make sure the top of the menu is
> > visible? Or do you know why the menu is scrolled to the bottom, since that
> > doesn't happen when you actually tap the menu button with your finger?
> 
> It looks like the problem here is the waitForExactText() in
> findAppMenuItemView():
> https://dxr.mozilla.org/mozilla-central/rev/
> 2dfb45d74f42d2a0010696f5fd47c7a7da94cedb/mobile/android/tests/browser/
> robocop/src/org/mozilla/gecko/tests/components/AppMenuComponent.java#162
> 
> Robotium's waitForText() will search the text in the UI and also scroll
> components to find it. In this case we are looking for the text "Forward"
> and even with scrolling the menu we won't find it. After that we are
> searching the view ourselves and are not only looking for the visible text
> but also inside contentDescription. This also has the side effect that every
> time we are searching for forward/back we will always wait for 7.5s
> (MAX_WAITTIME_FOR_MENU_UPDATE_IN_MS) because Robotium is trying to find the
> text first and is failing.
> 
> The test passes after removing the line (I do not know if a different test
> case might require the scrolling) and it's a bit faster too.
> 
> Another option would be to not use Robotium's search and just scroll up ->
> search view, scroll down -> search view - assuming that the menu will never
> be super long. And the perfect solution probably is to implement a
> searchText with Robotiums tools that will look into contentDescription too.

Thanks for looking into it! I decided to break this off into bug 1247366, and we can fix the test over there.

Comment 15

[:Margaret Leibovic]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=309737ce8608

Comment 16

[:Margaret Leibovic]

https://hg.mozilla.org/integration/fx-team/rev/f8466087ba15648dee4636d34608e9aee05b7da1
Bug 1234693 - Point Switchboard URLs to production mozilla-services endpoint. r=mfinkle

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f8466087ba15