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

Issue 896937 link

Starred by 2 users
Status: Duplicate
Merged: issue 913362
Owner:
sdy@chromium.org
Closed: Dec 12
Cc:
ccameron@chromium.org
█ ortuno@chromium.org
dominickn@chromium.org
█ bgalbs@google.com
pcovell@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

RemoteMacViews: Blurry app windows on high-DPI displays

Project Member Reported by mgiuca@chromium.org, Oct 18 
Chrome Version: 72.0.3584.0 Canary
OS: macOS

(Via ortuno@ who took screenshots.)

What steps will reproduce the problem?
On a high-DPI display:
(1) Turn on #enable-desktop-pwas and #create-app-windows-in-app flags.
(2) Install a PWA (e.g., https://mobile.twitter.com/)
(3) Open the PWA via the Applications folder (not chrome://apps).

What is the expected result?
Not blurry.

What happens instead?
The app window, including the web contents and title bar, is blurry. It looks like it's a 1X (low-dpi) rendering, scaled up to 2X, rather than being rendered at high-DPI.

Note that if you run the PWA from chrome://apps, it is nice and crisp, but that's because it isn't using RemoteMacViews (due to  Issue 896917 ).

See attached screenshot, clearly showing the difference between a RemoteMacViews window and a normal browser process window.
in-app-shim.png
74.2 KB View Download
no-app-shim.png
91.8 KB View Download

Comment 1 by ccameron@chromium.org, Oct 19 

So this is a weird thing -- in  issue 894082  it has been fixed ... but the fix was to update the Info.plist for apps.

So newly created apps are hi-dpi, but already-existing apps aren't.

I'm not sure if there exists a simple solution for already-existing apps, or how much we should pursue it. We may want to somehow-identify old apps, and exclude them from RemoteMacViews (this may come up in app signing).

Comment 2 by mgiuca@chromium.org, Oct 19 

Ah OK, if it only affects existing apps, I don't think it's a big deal since it only affects flag users.

Does it also affect existing hosted apps that've already been installed? And bookmark apps? (Probably does... in which case I think we need to migrate them.)

Comment 3 by ccameron@chromium.org, Oct 26 

We're going to have to update the Info.plist to support badging as well.

We should make sure that we force a rebuild of the "authoritative" packages in
  ~/Library/Application\ Support/Google/Chrome/<<Profile>>/Web\ Applications/...

Any .apps that have exist outside of there are harder to rebuild... I wonder if we should switch to doing symlinks.

Comment 4 by mgiuca@chromium.org, Dec 5

Labels: -Pri-1 Pri-2

Comment 5 by mgiuca@chromium.org, Dec 5

Labels: M-73

Comment 6 by ccameron@chromium.org, Dec 5

Cc: ccameron@chromium.org
Owner: sdy@chromium.org
->sdy@ -- there is likely a way to "enable" retina support besides adding NSHighResolutionCapable to Info.plist ... maybe we can hook into that mechanism?

Comment 7 by ccameron@chromium.org, Dec 10 

In the context of issue 913362, we may disable RemoteMacViews for pre-existing app shims, in which case this bug would be gone.

Comment 8 by ccameron@chromium.org, Dec 12

Mergedinto: 913362
Status: Duplicate (was: Assigned)
The fix for issue 913362 will stomp all pre-existing app shims, which will fix this issue.

Comment 9 by ccameron@chromium.org, Dec 22 

 Issue 917401  has been merged into this issue.
►

Sign in to add a comment