+tapted and ellyjones in case they have any ideas offhand.

My suspicion here is that, when in remote mode, NativeWidgetMac::Show and NativeWidgetMac::IsVisible are not atomic -- there is a delay between when Show is called and when IsVisible will return true.

I think we'll want to have a browser-side "predicted" value for the
- Show/Hide/IsVisible
- SetBounds/GetBounds
APIs. And potentially others (fullscreen comes to mind).

But, I can't reliably reproduce this in a debug build, so I'm not sure if this is indeed the issue.

I think assumptions in the Widget API will break down if `IsVisible()` is not synchronously true immediately after a Show()

Should we try to get all of widget_unittest.cc to pass in remote mode? There's already some plumbing for Mus to enable testing of remote widgets.

I'd go even further -- I think that if this is going to be maintainable long-term, we should use the async mode even when in a single process. We'll need to do something to "allow" sync calls (even though they won't be sync calls). I briefly played with adding a test mode in https://chromium-review.googlesource.com/c/chromium/src/+/1244097, but I've since abandoned it.

I've figured out the immediate issue and it turned out to be something different (but I'm surprised that the "IsVisible" isn't causing issues ... yet).

The "popup blocked" thing is not unique to PWA mode -- attaching a screenshot of it happening in a regular Chrome window. So we can ignore that (phew!)

The "hang for 5 seconds" was indeed the CATransactionCoordinator timing out. The bug here is that
- all of my mojo interfaces are associated
  - so they all use the same message queue
- we wait for up to 5 seconds to process the "new frame" message in resize/show
- but the way that we specify to do this is
  - "pump this task runner"
  - *not* "process this message queue"
- so we need to make sure that
  - "all mojo interfaces that use the same message queue also use the same task runner"

And ... I missed one -- BridgeFactoryImpl::BindRequest.

So if we happened to get a message on that interface (which we did!), it would block processing the message queue.

Deleted: Screen Shot 2018-10-15 at 23.38.38.png 436 KB

	Screen Shot 2018-10-15 at 23.38.38.png 436 KB View Download

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

commit 033fd2ad9251b93004b55fb929af4a6aea294e1d
Author: Christopher Cameron <ccameron@chromium.org>
Date: Tue Oct 16 20:25:15 2018

RemoteMacViews: Use resize run loop for bridge factory

Bug:  895700 
Change-Id: I4d62c1c4550609db7433b3109f920524f8aab77d
Reviewed-on: https://chromium-review.googlesource.com/c/1283948
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600105}
[modify] https://crrev.com/033fd2ad9251b93004b55fb929af4a6aea294e1d/ui/views_bridge_mac/bridge_factory_impl.mm

Tried testing the issue on mac 10.13.3 using chrome version #72.0.3583.0.
Attached a screen cast for reference.

Following are the steps followed to test the issue.
------------
1. Launched chrome and enabled flag #enable-desktop-pwas.
2. Navigated to gmail.com and created a gmail shortcut using wrench menu in order to dock to task bar.
3. Signed into gmail and composed a mail.
4. Clicked on the maximize button and observed that no window pop up.

ccameron@ - Could you please check the attached screen cast and please let us know if anything missed from our end in verifying the fix.

Thanks...!!

Deleted: 895700.mp4 4.8 MB

	895700.mp4 4.8 MB View Download

Thanks -- this is working now.

I think PWAs should disable popup-blocking, but I can bring that up with PWA folk.