sugupta@, what cros version you using <chrome://version>? And what device?
Perhaps you can also clarify the repro steps, or add some other details.
I'm unable to repro on a 1st gen Chromebook Pixel with version 61.0.3155.0.

Here's what I tried (I never saw a shelf missing):
0) Unplug the device from power and display.
1) Close the lid to put the device to sleep.
   (I'm not sure if this takes a while? I left it for ~1min)
2) Open the lid to wake from sleep and see the login screen.
3) Plug in an external display via mini display port.
4) Log in, observe shelf on device screen and external display.

I'm on a Chromebook Pixel 2015. Version 59.0.3071.134 (Official Build) (64-bit).

I saw this issue as recently as today in the office. Now, I'm at home and was able to recreate it. I simply plugged my monitor in before signing in. Then, I signed in. Upon signing in, the shelf is not visible on my device screen.

In case it matters, my monitor cord is DisplayPort to USB-C.

From the detailed build info section:
9460.73.0 (Official Build) stable-channel samus
Firmware
Google_Samus.6300.174.0
Channel
Currently on stable
CHANGE CHANNEL
ARC Version
4127355
Blink
537.36 (@0)
V8
5.9.211.41
User Agent
Mozilla/5.0 (X11; CrOS x86_64 9460.73.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.134 Safari/537.36
Command Line
/opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=26.0.0.102 --ui-prioritize-in-gpu-process --use-gl=egl --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --arc-availability=officially-supported --user-data-dir=/home/chronos --max-unused-resource-memory-usage-percentage=5 --login-profile=user --enable-natural-scroll-default --has-chromeos-keyboard --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/default_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/default_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --enable-prefixed-encrypted-media --enable-consumer-kiosk --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --login-user=sugupta@google.com --login-profile=a2d8078560f851c767e29ff0e2b9628e47f72322 --flag-switches-begin --enable-hotword-hardware --flag-switches-end --vmodule=*arc/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*plugin*=2,*zygote*=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2
Build Date
Thursday, July 13, 2017

Interestingly, I just switched users (control + alt + >), switched back, and the shelf is now visible.

Oh, and I submitted a alt + shift + i as soon as the problem manifested now (~8:43 pm ET). I gave it the same title as this bug.

Sorry for the multiple posts.

Thanks for the bug report!

A couple questions:
* Is this a corp Chromebook?
* Is it the login screen (just after you booted the machine) or the lock screen (after lid close and reopen)?  It sounds like the lock screen, but I wanted to be sure.
* Are you plugging in the monitor before or after opening the lid? (You said after, but I'm curious if the problem happens you plug things in the other order.)

I don't see screen shots here -- I presume both the internal and external displays have wallpaper on them after monitor connect?

Thanks for filing a feedback report. I'm OOO but I can dig through feedback when I return.

msw, just FYI, we probably need Chrome logs from this so we can see the monitor attach working. The probably here might be related to code in RootWindowController around shelf init on secondary monitors.

Also, it's very odd that the shelf is missing from the internal display, not the external. I wonder if somehow the external display is being designated as "primary".

* Yes. Corp Chromebook.
* Lock screen. I see that each time I get back to my desk. I rarely see the login screen day-to-day.
* I plug in the monitor after opening the lid but before logging in. Now, because of this bug, I plug in after logging in.
* The screenshots were in the email thread. I attached them here now, too. See the file names to know which is which.
* Yes, I designate my external as primary. When I'm using it, I want it to be my main screen with the device's monitor being secondary. I do this within Settings > Displays > Screen = Extended Display for my device's screen.

Thanks. Please don't worry about this while you're OOO.

Deleted: External monitor.png 1.2 MB

	External monitor.png 1.2 MB View Download

Deleted: Device screen.png 1.3 MB

	Device screen.png 1.3 MB View Download

Okay, making the external display my primary allowed me to repro on device.
Sadly, I wasn't able to repro on my desktop chromeos build.

The problem is something like this:

0. Ash starts at the lock screen with the primary display == internal display. There's an existing RootWindowController (RWC) and Shelf.
1. External display connected. Ash makes new display and new RWC. This creates a new ShelfLockingManager (SLM) and new Shelf.
2. Ash sends OnShelfInitialized to chrome over mojo, with the display ID of the external display.
3. Ash swaps the WindowTreeHost/RWC of the internal and external display, in order to designate the external display as primary. This means the secondary RWC and secondary Shelf are on the internal display.
4. Chrome responds with shelf alignment pref for the external display ID. SLM stores it because the screen is locked.
5. Screen is unlocked. SLM applies the correct pref to the external (primary) display. However, SLM does not have a pref value for the internal (secondary) display, so it never sets alignment, so alignment stays as bottom-locked and the shelf does not appear.

Frankly, I'm a little surprised this ever worked. It's possible the old, pre-mojo code would somehow call into chrome with the internal display id when initializing the shelf. It could be due to the fact that ash::ShelfController uses this to get the display id:

Screen::GetScreen()->GetDisplayNearestWindow(shelf->GetWindow())

I wonder if changes to display management have changed which display is primary when RWC is initialized.

Either way, we somehow need to look up or save the internal display shelf alignment when making an external display primary.

(Hacking note: This can be reproduced on linux desktop by changing DisplayManager::AddRemoveDisplay() to always use the same ID for the new display, then hitting Ctrl-Alt-D as usual.)

There are a couple of cases (not new) that trigger resetting the display id a RootWindow is associated with. If the shelf is caching the display id of a root window in some way, then the shelf likely needs to observe when the display ids change to update state.

Chrome caches per-display profile prefs for each shelf using the display id. If the shelf objects themselves aren't recreated, but 'moved' to a different display by reassigning display ids for existing root windows, something needs to observe those id changes to update the shelf state accordingly.

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

commit 9a6ef135259507439b954aeaef887cf0ebc74a10
Author: James Cook <jamescook@chromium.org>
Date: Wed Aug 02 18:48:36 2017

cros: Fix invisible shelf when external display attached at lock screen

When an external display is attached a new RootWindowController and new
shelf are created for that display. Shelf alignment is loaded from prefs.
However, if the external display is marked as primary then the internal
and external displays are swapped. This means that the (new) shelf now
on the internal display never reloads its alignment from prefs. Since
the screen was locked at attach time, the shelf stays in the
bottom_locked state and never becomes visible.

Fix this by reloaded shelf alignment from prefs on display swap.

Bug:  748291 
Test: added to ash_unittests
Change-Id: I5780dd3ca3b796b6f46fea9bc46fe875d123701e
Reviewed-on: https://chromium-review.googlesource.com/597410
Commit-Queue: James Cook <jamescook@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491452}
[modify] https://crrev.com/9a6ef135259507439b954aeaef887cf0ebc74a10/ash/shelf/shelf.cc
[modify] https://crrev.com/9a6ef135259507439b954aeaef887cf0ebc74a10/ash/shelf/shelf.h
[modify] https://crrev.com/9a6ef135259507439b954aeaef887cf0ebc74a10/ash/shelf/shelf_unittest.cc
[modify] https://crrev.com/9a6ef135259507439b954aeaef887cf0ebc74a10/ash/shelf/shelf_view_unittest.cc

sugupta - thanks for the detailed bug report. Fix will show up in M62. In the mean time, if the shelf is invisible you might be able to make it show up by right clicking on the desktop and turning "auto hide" on and off. Or just do what you're doing now and wait to unlock before connecting the monitor.

Thanks for the fix, James. I'll keep an eye out for it.

Verified on M62 build 9827.0.0

Working. Thanks.