Actually, the page does not become blank in this case - I was mistaken. Instead, the page stays there and gives the appearance that the network is still available, but it actually is not. Pressing "connect" produces the following error to be logged:

"Connect Failed: Error.InvalidNetworkGuid: <guid>"

Removing this from M-61. After  issue 757520  was fixed, this situation is very rare since it takes up to 2 hours for a device to be removed from the cache.

When the user gets into this situation, nothing bad happens except that the page is out of date. Let's punt this to a future release.

Another issue I noticed: the Mobile data subpage can also get stale.

Repro:
(1) Go to Mobile data subpage.
(2) Disable Bluetooth.

Expected: You get routed back to the top-level settings page. Or, perhaps, we have some UI telling the user to enable Bluetooth?

Actual: Get stuck on page, and toggle is disabled (as in, clicking it does nothing). There is no text, so it's very confusing what's happening.

I've gotten a few more reports about this issue. I'm going to prioritize getting a fix into M-63.

One more issue I've noticed: clicking on a network name in the mobile data subpage often does not cause the network row to update immediately (i.e., it takes a bit for "Connecting..." to appear and for the icon to start animating). I'll this this as part of this bug as well.

Re: comment #7, Steven discovered that one source of the lag is that we are emitting a ton of unnecessary events which are clogging up the JS message loop. He's going to fix that, which we suspect will improve the update speed of the UI during connection state changes.

+Shiba/Elizabeth

Hi UX designers - after talking with Steven a bit on this, I think it may be worthwhile to change the behavior originally decided. Here is the chain of events:

(1) Chromebook discovers phone and adds it to Mobile data settings.
(2) User clicks on phone to bring up the "detail" page which includes information about signal strength, carrier, etc. Additionally, this page has a "CONNECT" button, which, when clicked, initiates a connection to the device.
(3) Chromebook can no longer find the phone. Thus, the "CONNECT" button no longer works. Clicking the button does nothing, and users will be confused about why this is broken.

Now, the potential fixes:
(A) Close the "detail" page, and go back to the top-level Mobile data page. It may be confusing to users why the page closed without them doing anything.
(B) Hide/disable the "CONNECT" button, but keep the page open. Users can still see information about the phone, but they can no longer initiate a connection. It may be confusing to users why the "CONNECT" button stopped working without them doing anything.
(C) Replace the "CONNECT" button with some text or an icon which tells the user that the phone has been lost (perhaps "Your _____ can no longer provide a connection").

When I originally talked to Elizabeth, she suggested that I move forward with option (A) above. However, Steven suggested some alternatives, since it could be confusing that the page just disappears without the user explicitly taking an action. What do you think is the correct path forward?

Hi Kyle,

I recommend Option C because with A the user will get the impression of a successful connection and with B hiding alone won't work. 

Attached a screenshot of what I recommend. Will follow up with Elizabeth to see if this pattern exists on CrOS dialogs. 

Deleted: Screen Shot 2017-11-14 at 6.53.04 PM.png 239 KB

	Screen Shot 2017-11-14 at 6.53.04 PM.png 239 KB View Download

qq: Kyle is there anything the user can do to reconnect to this phone? Steps we could ask the user to take/try?

Hi Shiba,

Re: comment #11: Your mock shows the "tether connection confirmation dialog", not the "detail" page. I've attached a screenshot of the page I'm referring to.

Re: comment #12: To be clear, the phone was never connected at any point in the flow I'm describing. In this situation, the Chromebook scans for the phone and finds it, then scans again and cannot find it. There is nothing the user can do to make the phone re-appear until a subsequent scan picks up the phone again.

Sorry - forgot to attach the screenshot. Attached this time.

Deleted: Screenshot 2017-11-15 at 10.10.54 AM.png 1.1 MB

	Screenshot 2017-11-15 at 10.10.54 AM.png 1.1 MB View Download

I'm not sure if we have this pattern anywhere else in CrOS. But I would recommend something along the lines of attached screenshot. My best stab at the copy.

elizabethchiu@ if we don't use red anywhere for error states, grey in this case would also work.

Deleted: Screen Shot 2017-11-15 at 12.45.39 PM.png 374 KB

	Screen Shot 2017-11-15 at 12.45.39 PM.png 374 KB View Download

Hi Shiba - thanks for the quick turnaround!

However, I think the wording could cause confusion for some users. The phone was never connected in the first place, so I'm not sure that the phrase "lost connectivity" clearly differentiates itself from the previous state of "Not Connected" (see screenshot in comment #14).

To be clear, we need to differentiate between:
(1) Not connected, but the Chromebook still knows about the phone and can connect by pressing the "CONNECT" button.
(2) Not connected, and the Chromebook cannot find the phone to initiate a connection.

(1) I think in this case, we can just show "Not connected"

(2) Since user can't find the phone and initiate to connect, can we just not show the phone?

Re: comment #17:

(1) Sounds good - we also agree that this should remain the case.
(2) The issue that we're referring to occurs when the user is already viewing the details page for that network. Please refer to comment #10 for the repro steps. Since we're already viewing the page, we can either close the page altogether (option A from comment #10) or add some sort of messaging (option C from comment #10). Shiba suggested that we move forward with option C (see comment #11), but we haven't been able to come up with the correct string to use to denote this situation.

A few suggestions here:
1/ Unable to connect to your Pixel XL
2/ Unable to detect your phone, please try again.
3/ Unable to find your Pixel XL

Deleted: 0.3a - not conected .png 849 KB

	0.3a - not conected .png 849 KB View Download

Hi Elizabeth - thanks for the mock, but that's the "tether connection confirmation dialog", not the "detail" page. Please see comment #13 and comment #14.

Hi Kyle,
Please let me know what do you think about these following options:
1/ Unable to connect to your Pixel XL
2/ Unable to detect your phone, please try again.
3/ Unable to find your Pixel XL

Deleted: 0.3a - not conected .png 364 KB

	0.3a - not conected .png 364 KB View Download

Thanks! I would prefer wording which does *not* use the word "connected" at all, since the state of the connection is orthogonal to the issue at hand. Also, I don't like the phrase "please try again," since the user just needs to wait until the phone is scanned again, meaning that there is really no actionable feedback to provide.

My preferences:
"Unable to detect your phone"
"Your phone has been lost"
"Cannot find your phone"
etc.

Let me know what you decide! :)

I think "Unable to detect your phone" is the best out of three. Let's go with that.

Sounds good - thanks for the input!

I've implemented almost all of the change (see [1]). The only thing I still need is the red (!) icon in comment #19. Elizabeth/Shiba, can you please provide the appropriate SVG? Thanks!

[1] https://chromium-review.googlesource.com/c/chromium/src/+/818465

In the mock in comment #21, both names would be the same ("Google Pixel" and "Pixel XL).

Would it make more sense just to say "Unable to connect to your device"? This is already likely to look pretty cramped in some languages (e.g. German), duplicating the device name is not going to help.

Here are the new icons: https://drive.google.com/open?id=0B_2Uyb2Rhx2OVmJRY2tnbDYyT28

To Steven's comment, I think "Unable to connect to your device" sounds good to me. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7581d17d454ec4a9317832a374cd57e517c068d

commit d7581d17d454ec4a9317832a374cd57e517c068d
Author: Kyle Horimoto <khorimoto@google.com>
Date: Tue Dec 12 18:56:25 2017

[CrOS Tether] When a network has become lost, display a warning.

This remedies the following situation:
  (1) Host scan discovers a potential Tether host device.
  (2) User visits the "internet detail page", which displays information
      about that Tether host.
  (2b - optional) User opens the tether confirmation dialog.
  (3) A subsequent host scan can no longer find the device.
  (4) User can no longer connect to the device, but has no idea why.

This CL places a warning in red text on both the internet detail page
and the tether confirmation dialog when this situation occurs. Likewise,
this CL also adds a warning in the detail page for Wi-Fi networks which
have gone out of range.

Bug:  750955 , 672263
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I75666e25a0df0add94ea469599641b0703b64d76
Reviewed-on: https://chromium-review.googlesource.com/818465
Commit-Queue: Kyle Horimoto <khorimoto@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523496}
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/app/settings_strings.grdp
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/browser/resources/settings/icons.html
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/browser/resources/settings/internet_page/internet_detail_page.html
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/browser/resources/settings/internet_page/internet_detail_page.js
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/browser/resources/settings/internet_page/tether_connection_dialog.html
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/browser/resources/settings/internet_page/tether_connection_dialog.js
[modify] https://crrev.com/d7581d17d454ec4a9317832a374cd57e517c068d/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc