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

Issue 135382 link

Starred by 9 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Jul 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chrome Extension dropdown menus corrupted for when compositing is enabled

Reported by xangent...@gmail.com, Jul 1 2012

Issue description

Chrome Version       : 22.0.1191.1
OS Version: OS X 10.7.4; Macbook Pro - Retina

What steps will reproduce the problem?
 1. Install any of the given Chrome extensions from Chrome Web Store: Google Voice, Screen Capture, Clip to Evernote, Chat for Google
 2. On retina-display Mac, open an extenion's dropdown menu by selecting the button

What is the expected result?
 * The menu should display in the same visible dimensions as non-retina displays.
 * The menu should be "on top" and fully opaque.
 * The menu should be fully functional.

What happens instead?
 * The Mac's background is visible _through_ the Chrome window for a majority of the menu.
 * Only a portion of the menu is visible; visible buttons/features are functional.
 * Even where the display is bleeding through, the buttons from the menu are selectable (see screenshot).

Other extensions that do not rely on the drop-down menu style work fine - a notable example is Chat for Google loads the independent menu docked to the bottom of the display without any issue.


UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1191.1 Safari/537.1



 
desktop visible through chrome.png
773 KB View Download
cursor position.png
196 KB View Download
Cc: thakis@chromium.org
Labels: -Area-Undefined Area-UI Feature-Extensions macdpi
Labels: Action-BisectNeeded
This used to work fine I think.
Mergedinto: 134285
Status: Duplicate
I can't repro with Look Of Disapproval. I _can_ repro with Death Metal Rooster. The problem goes away in Death Metal Rooster if I disable flapper. So this is likely  issue 134285 .
Labels: -Pri-2 -Action-BisectNeeded Pri-1 Mstone-21 ReleaseBlock-Stable
Mergedinto:
Status: Untriaged
I can repro this with Death Metal Rooster on the m21 dev channel, which doesn't ship flapper. So this isn't a flapper thing.

Someone should look into this for m21.
Labels: Feature-HighDPI
Status: Available
Status: Untriaged
And once more, for the mac triage

Comment 8 by sail@chromium.org, Jul 12 2012

 Issue 136913  has been merged into this issue.

Comment 9 by sail@chromium.org, Jul 12 2012

Cc: sail@chromium.org

Comment 10 by dav...@gmail.com, Jul 12 2012

In my experience, it's not related to any one plug-in, but occurs randomly for some plug-in badge popup windows. When I have several plugins with badge icons, hovering over them generally produces some working, and some corrupted hover-windows. To repro, it probably pays to install a bunch of badged plugins and hover over a bunch of them until you see one corrupted. 

I run Flashblock, Hide Images, Chrome to Phone, Zoom All -- and there is always one of them corrupted when I try. 

Comment 11 by sail@chromium.org, Jul 13 2012

Owner: sail@chromium.org
Status: Assigned
Working on this.
I thought my fix for  bug 132762  would fix this as well but guess now.

Comment 12 by sh...@chromium.org, Jul 13 2012

Cc: sh...@chromium.org

Comment 13 by sh...@chromium.org, Jul 14 2012

Cc: a...@chromium.org
Sail (and Avi), I see this problem code in content/browser/web_contents/web_contents_view_mac.mm:
void WebContentsViewMac::GetContainerBounds(gfx::Rect* out) const {
  // Convert bounds to window coordinate space.
  NSRect bounds =
      [cocoa_view_.get() convertRect:[cocoa_view_.get() bounds] toView:nil];

  // Convert bounds to screen coordinate space.
  NSWindow* window = [cocoa_view_.get() window];
  bounds.origin = [window convertBaseToScreen:bounds.origin];

  // Flip y to account for screen flip.
  NSScreen* screen = [[NSScreen screens] objectAtIndex:0];
  bounds.origin.y = [screen frame].size.height - bounds.origin.y
      - bounds.size.height;
  *out = gfx::Rect(NSRectToCGRect(bounds));
}

note the lack of conversion to base coordinates.  I believe that this line:
  bounds = [cocoa_view_.get() convertRectToBase:bounds];
should go somewhere between -convertRect:toView: and -convertBaseToScreen:.

BUT, I have not been able to replicate the problem in a debug build.  I'll try a release build, but it'll need to ... build.  So I might not get around to it this evening.

Comment 14 by sh...@chromium.org, Jul 14 2012

It also looks like the -convertBaseToScreen: call in extension_popup_controller.mm is using a coordinate which wasn't previously converted to base.  But I freely admit that that one is too subtle for me (and I can't see how it would cause what I'm seeing with canary).

I haven't been able to repro using a release build from the same point as 1205 canary.  I have experimented with flapper, doesn't seem to matter for my repro case.

Comment 15 by sh...@chromium.org, Jul 14 2012

I wonder if there could be any remotest possibility of a 10.5 SDK interaction.  I'm building on Lion, thus with 10.6 SDK.

Comment 16 by sh...@chromium.org, Jul 16 2012

Aha!  Setting 1.5x in Quartz Debug causes the window itself to be the wrong size.  I suspect an interaction.

Comment 17 by a...@chromium.org, Jul 17 2012

> void WebContentsViewMac::GetContainerBounds(gfx::Rect* out) const {
>   // Convert bounds to window coordinate space.
>   // Convert bounds to screen coordinate space.
> }
> 
> note the lack of conversion to base coordinates.

This code is correct as written. What is the "base coordinates" that you're referring to? There is no such thing.

> I believe that this line:
>  bounds = [cocoa_view_.get() convertRectToBase:bounds];
> should go somewhere between -convertRect:toView: and -convertBaseToScreen:.

Google "convertRectToBase". Result #2 is the Chromium PSA to not use convertRectToBase.

DO NOT USE -convertRectToBase:.

There is no such thing as "base coordinates". The use of "base" in -[NSWindow convertBaseToScreen:] refers to "window base coordinates" which is the window coordinate system. Therefore it's appropriate to pass it the window coordinates obtained from -convertRect:toView:nil.

On the other hand, -[NSView convertRectToBase] does NOT refer to window base coordinate system. It can refer to either device pixels or the coordinate system of the CALayer backing the view, neither of which is correct to call "base coordinates".

I haven't looked into this, and I'm sure something's wrong somewhere. But this coordinate code looks good to me.

Comment 18 by sh...@chromium.org, Jul 17 2012

Yeah.  I read through the conversions with "base" in the name from view->screen, and then backwards, and I agree that I was confused.  Sailesh apparently has been able to repro in a build he made, and we're suspecting that there's something related to 10.5 SDK involved.

Comment 19 by a...@chromium.org, Jul 17 2012

We switched to the 10.6 SDK earlier this afternoon; hope that helps.

Comment 20 by sail@chromium.org, Jul 18 2012

(reposting from the Mac bug).
So my comment above was wrong. This isn't a bug in the flash code. The reason this didn't reproduce in the mouse lock sample is because the mouse lock code uses 2D drawing code.

We have a sample plugin that uses 3D drawing code, gles2.cc. I updated it to use flash full screen and I can reproduce this bug.

I've attached that patch I used to reproduce this bug.
gles2.diff
3.0 KB View Download
shess: FYI, you can't use QuartzDebug on 10.6 to debug hidpi stuff. All that code changed significantly in 10.7.

Comment 22 by sail@chromium.org, Jul 19 2012

> We switched to the 10.6 SDK earlier this afternoon; hope that helps.
I can still reproduce this with today's Canary build (22.0.1211.0) so I don't think it helps.

Comment 23 by sail@chromium.org, Jul 19 2012

Status: Started
Working on this 100% now.

Just a quick recap:
  - can repro on Chrome Canary
  - can't repro on local build of Chrome or Chromium. Using the Chrome Canary user data directory didn't help.
  - using --disable-accelerated-compositing causes the bug to go away

As a first step I'm trying to get this bug to repro on a local build.

Comment 24 by sail@chromium.org, Jul 19 2012

Progress!

I can get this to repro in Chromium by forcing the extension to use a 3D transform.

I have no idea why Chromium and Chrome are behaving differently.

I've attached a sample extension that can be used to reproduce this.
my_extension.zip
8.5 KB Download
We're doing a "force composited rendering" 5% experiment on chrome, maybe you were part of that. You can also toggle this on about:flags. Sorry, I should've thought of that earlier today :-/

Comment 26 by sail@chromium.org, Jul 20 2012

Looks like an Apple bug. Applying a blur filter to window messes up OpenGL drawing. Attached a sample app to demonstrate. Will file a bug.
gl_Test.zip
40.8 KB Download

Comment 27 by sail@chromium.org, Jul 20 2012

Labels: -macdpi -Feature-HighDPI
Summary: Chrome Extension dropdown menus corrupted for when compositing is enabled
Apple bug:
http://openradar.appspot.com/11920246

Workaround out for review:
https://chromiumcodereview.appspot.com/10808046/

Removing the macdpi flag since this bug can be reproduced at 1x scale factor as well.
Project Member

Comment 28 by bugdroid1@chromium.org, Jul 20 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=147628

------------------------------------------------------------------------
r147628 | sail@chromium.org | 2012-07-20T09:17:11.946412Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/info_bubble_window.mm?r1=147628&r2=147627&pathrev=147628
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/extensions/extension_popup_controller.mm?r1=147628&r2=147627&pathrev=147628
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/info_bubble_window.h?r1=147628&r2=147627&pathrev=147628

Disable blurring for extension bubbles

Extension bubbles in HiDPI mode were drawing incorrectly.

The problem was that the blur filter we placed on bubble windows was interfering with OpenGL drawing.

I've filed an Apple bug about this:
  http://openradar.appspot.com/11920246
In the meantime this CL disables the blur filter for extension bubbles.

BUG= 135382 
TEST=


Review URL: https://chromiumcodereview.appspot.com/10808046
------------------------------------------------------------------------

Comment 29 by sail@chromium.org, Jul 20 2012

Labels: Merge-Requested

Comment 30 by kareng@google.com, Jul 20 2012

ok let's let this go to canary and then we'll merge once thakis can confirm.
Looks fixed to me on canary.
I just tested this on a Retina Macbook Pro with the 1password plugin and it is working now.  Thanks SOOO much!
Agreed - issue is resolved per my testing on last Canary update with several flapper extensions (Evernote, Google Voice, Google Screen Capture).

Note that I had all the flapper extensions disabled, and they were still corrupted on enabling with the fixed build; but a browser restart resolved the issue.  I had enabled all, so I can't test if this would happen in each case or just in the case of the original update before restart.

Thanks for the fix!

Comment 34 by kareng@google.com, Jul 23 2012

Labels: -Merge-Requested Merge-Merged merge-merged-1180
Status: Fixed
Project Member

Comment 35 by bugdroid1@chromium.org, Jul 24 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=147882

------------------------------------------------------------------------
r147882 | sail@chromium.org | 2012-07-23T17:49:52.224077Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/ui/cocoa/info_bubble_window.h?r1=147882&r2=147881&pathrev=147882
   M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/ui/cocoa/info_bubble_window.mm?r1=147882&r2=147881&pathrev=147882
   M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/ui/cocoa/extensions/extension_popup_controller.mm?r1=147882&r2=147881&pathrev=147882

Merge 147628 - Disable blurring for extension bubbles

Extension bubbles in HiDPI mode were drawing incorrectly.

The problem was that the blur filter we placed on bubble windows was interfering with OpenGL drawing.

I've filed an Apple bug about this:
  http://openradar.appspot.com/11920246
In the meantime this CL disables the blur filter for extension bubbles.

BUG= 135382 
TEST=


Review URL: https://chromiumcodereview.appspot.com/10808046

TBR=sail@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10805059
------------------------------------------------------------------------
Status: Verified
Verified as Fixed with 21.0.1180.55.
Screen Shot 2012-07-25 at 11.48.13 AM.png
515 KB View Download
Project Member

Comment 37 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 38 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Feature-Extensions -Mstone-21 Cr-Platform-Extensions Cr-UI M-21
Project Member

Comment 39 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment