New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 913397 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 17
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Mac PWAs: App Info Dialog is comically enormous

Project Member Reported by dominickn@chromium.org, Dec 10

Issue description

This is with chrome://flags/#create-app-windows-in-app. Open a PWA, then go 3-dot menu -> App Info, resulting in this very empty and very large app/page info dialog.
 
Screen Shot 2018-12-10 at 22.00.54.png
185 KB View Download
This bug goes away as soon as there is at least one permission entry in the dialog (see attached).
Screen Shot 2018-12-10 at 22.15.09.png
171 KB View Download
This is a recent regression -- a bisect should find when this happened.
Ran a bisect. Got it down to: https://chromium.googlesource.com/chromium/src/+log/49fe04d0a39a638f31706cb28f939e6682d2f354..fb8c90427b9e23970dad9b463e755c556bb07724 which is when the app menu (and the ability to see App Info) was implemented. Looks like this has always been the case.
Labels: Pri-2
Bulk downgrading some bugs to P2.
Labels: -Pri-2 Pri-3
P3 in fact.
Cc: nyerramilli@chromium.org rbasuvula@chromium.org
 Issue 919034  has been merged into this issue.
The BubbleHeaderView::security_details_label_ is 560px high for some reason when it's normally only 60px.
Seems like there's a race between the security_details_label_ having its width updated from 30px to 288px, the text getting set by SetIdentityInfo() and the bounds of the new Widget getting set based on the preferred size of the view.

Comment 9 by alancutter@chromium.org, Jan 17 (6 days ago)

So the normal flow is:
 - PageInfoBubbleView is created with 0x0 size.
 - Widget is created with GetPreferredSize as initial bounds.
 - Native widget sets the initial preferred size on NSWindow which plumbs its actual size back to the root view, updating the PageInfoBubbleView to be its initially preferred size.
 - PageInfo object is created, updates the identity info text, forces a layout and tells the widget to update to the new size via SizeToContents().
 - Native widget sets new size on NSWindow which plumbs its actual size back to the root view, updating the PageInfoBubbleView to be its new size.

In the PWA case communication with the NSWindow becomes async:
 - PageInfoBubbleView is created with 0x0 size.
 - Widget is created with GetPreferredSize as initial bounds.
 - PageInfo object is created, updates the identity info text, forces a layout *USING 0x0 AS THE OUTER CONTAINER SIZE* and tells the widget to update to the broken size via SizeToContents().
*Async pause*
 - Native widget sets the initial preferred size on NSWindow which plumbs its actual size back to the root view, updating the PageInfoBubbleView to be its initially preferred size.
 - Native widget sets the broken size on NSWindow which plumbs its actual size back to the root view, updating the PageInfoBubbleView to be the broken size.

Essentially we need the PageInfoBubbleView to have its preferred size set before the PageInfo object updates its inner contents, forcing broken layouts and forcing widget size updates to these broken sizes.

Comment 10 by alancutter@chromium.org, Jan 17 (6 days ago)

Screenshots for WIP CL: https://chromium-review.googlesource.com/c/chromium/src/+/1415612
before.png
140 KB View Download
after.png
118 KB View Download
Project Member

Comment 11 by bugdroid1@chromium.org, Jan 17 (6 days ago)

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

commit 8194c0d23ec069cd3d3c8bd92997249e2af5740e
Author: Alan Cutter <alancutter@chromium.org>
Date: Thu Jan 17 06:49:48 2019

Fix layout race condition causing page info to be too tall for Mac PWA windows

This CL ensures the PageInfoBubbleView sets itself to its preferred size
before its childrens' sizes are updated, layed out and have the new
size pushed to the widget.

This is required for Mac PWA windows because the process of creating
the bubble widget will asynchronously update the NSWindow size and
asynchronously push the new size back onto the root view. This means
we cannot rely on this new size being set immediately after creating
the widget.

Before: https://bugs.chromium.org/p/chromium/issues/attachment?aid=375442&signed_aid=jQwc52ejdR5XkD7h5Yohew==&inline=1
After: https://bugs.chromium.org/p/chromium/issues/attachment?aid=375443&signed_aid=9kfGT_9rTwXnaYlX7-f8_g==&inline=1

Bug:  913397 
Change-Id: Ic1abfd21fe4fe718cbcf5b07ea88dc8e969a9d78
Reviewed-on: https://chromium-review.googlesource.com/c/1415612
Reviewed-by: Patti <patricialor@chromium.org>
Commit-Queue: Alan Cutter <alancutter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623609}
[modify] https://crrev.com/8194c0d23ec069cd3d3c8bd92997249e2af5740e/chrome/browser/ui/views/page_info/page_info_bubble_view.cc

Comment 12 by alancutter@chromium.org, Jan 17 (6 days ago)

Status: Fixed (was: Assigned)

Sign in to add a comment