My favorites | Sign in
Logo
             
New issue | Search
for
| Advanced search | Search tips
Issue 3264: standard window controls and grey line rendered when right clicking on caption area
7 people starred this issue and may be notified of changes. Back to list
 
Reported by ben.at.chromium.org, Oct 08, 2008
What steps will reproduce the problem?
1. Run the browser with --magic_browzR for a while, with many tabs
2. Right click on the caption area.

What is the expected output? What do you see instead?
- observe that the standard windows window controls are painted over the
Chrome window controls, as well as a grey line across the entire window.
The glitch disappears when the window is repainted.

This appears to be painting done by WM_ENTERMENULOOP.
Comment 1 by ben.at.chromium.org, Oct 09, 2008
(No comment was entered for this change.)
Status: Fixed
Comment 2 by ben.at.chromium.org, Oct 09, 2008
Not fixed :-(
Status: Assigned
Comment 3 by ben.at.chromium.org, Oct 17, 2008
I believe I have mostly mitigated this now.
Status: Fixed
Comment 4 by ben.at.chromium.org, Oct 19, 2008
Nope.
Status: Assigned
Comment 5 by ben.at.chromium.org, Oct 20, 2008
Fixed now!
Comment 6 by venkataramana@chromium.org, Nov 19, 2008
Is it fixed ? I can still reproduce this consistently with 0.4.154.23(r5672) with
repro steps mentioned for the  Issue 2456  !

-Venkat.
Comment 7 by pkasting@chromium.org, Jan 14, 2009
This is indeed not fixed.

I found an MSDN blog with some useful info bits at: http://blogs.msdn.com/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx

"Overall, the trickiest part of this scenario is that Windows will often try to draw 
the default title bar, even though there’s no non-client area. It does this at 
generally predictable times, when Windows would generally have had to perform a 
repaint to update the title bar. This includes maximizing, restoring, minimizing, 
setting the icon or text, and activating/deactivating the window, or whenever the 
enabled state of any of the caption buttons gets toggled. To avoid this, these types 
of changes can be detected and intercepted.

"For messages like WM_SETTEXT and WM_SETICON, you can avoid the redraw by temporarily 
removing the WS_VISIBLE style from the Window and let the change get processed, and 
then restore the style afterwards.

"For WM_NCACTIVATE, the MSDN documentation is incomplete. Intercepting the call and 
passing it to user32!DefWindowProc with an lParam of -1 will cause the system to not 
redraw the caption area. Handling WM_NCACTIVATE in this way allows you to not have to 
handle WM_ACTIVATE."

They also linked to actual code to do everything!  Sadly it's in WPF but I suspect it 
could be parsed to figure out what is going on.  See http://code.msdn.microsoft.com/chrome .

Comment 8 by pkasting@chromium.org, Jan 14, 2009
It looks from a brief glance at that code like it's using the WS_VISIBLE trick during 
handling of WM_SIZE, WM_WINDOWPOSCHANGED, WM_SETTEXT, and WM_SETICON, and using the 
WM_NCACTIVATE trick they describe above.
Comment 9 by ben.at.chromium.org, Feb 23, 2009
 Issue 3773  has been merged into this issue.
Comment 10 by ben.at.chromium.org, Feb 28, 2009
 Issue 6022  has been merged into this issue.
Cc: anan...@chromium.org
Comment 11 by bugdroid1@chromium.org, Mar 02, 2009
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=10757 

------------------------------------------------------------------------
r10757 | ben@chromium.org | 2009-03-02 16:28:00 -0800 (Mon, 02 Mar 2009) | 34 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser_focus_uitest.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/browser_views.vcproj?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_impl.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_impl.h?r1=10757&r2=10756
   D /trunk/src/chrome/browser/views/frame/aero_glass_frame.cc
   D /trunk/src/chrome/browser/views/frame/aero_glass_frame.h
   D /trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.cc
   D /trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_frame.cc
   R /trunk/src/chrome/browser/views/frame/browser_frame.h (from /trunk/src/chrome/browser/views/frame/aero_glass_frame.h:10646)
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_view.cc?r1=10757&r2=10756
   D /trunk/src/chrome/browser/views/frame/browser_window_factory.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/glass_browser_frame_view.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/glass_browser_frame_view.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_browser_frame_view.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_browser_frame_view.h
   D /trunk/src/chrome/browser/views/frame/opaque_frame.cc
   D /trunk/src/chrome/browser/views/frame/opaque_frame.h
   D /trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc
   D /trunk/src/chrome/browser/views/frame/opaque_non_client_view.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/hung_renderer_view.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/info_bubble.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_renderer.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_renderer.h?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.h?r1=10757&r2=10756
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_view.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_view.h
   D /trunk/src/chrome/views/custom_frame_window.cc
   D /trunk/src/chrome/views/custom_frame_window.h
   D /trunk/src/chrome/views/default_non_client_view.cc
   D /trunk/src/chrome/views/default_non_client_view.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/native_frame_view.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/native_frame_view.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.h?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/root_view.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/root_view.h?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/view.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/view.h?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/views.vcproj?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget.h?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget_win.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget_win.h?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/window.cc?r1=10757&r2=10756
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/window.h?r1=10757&r2=10756

Support DWM switching.

This completes the collapsing of window types and browser frames around a single class: views::Window. CustomFrameWindow is removed with this change.

The Browser window is represented by a single views::Window subclass: BrowserFrame, which replaces both AeroGlassFrame and OpaqueFrame.

NonClientView is now a container of two sibling classes - the Window's ClientView (in the Browser's case, BrowserView), and a NonClientFrameView subclass, which provides the rendering for the non-client portions of the window. These Views are siblings rather than the ClientView a child of the NonClientFrameView because when the DWM is toggled, the ClientView would have to be re-parented. Many Views make the assumption they are only inserted into a View hierarchy once, and so this is problematic. By having the views be siblings, this is avoided.

With this in mind, all of the former NonClientViews now become NonClientFrameView subclasses:

DefaultNonClientView -> CustomFrameView
(non-existent, NonClientView) -> NativeFrameView
AeroGlassNonClientView -> GlassBrowserFrameView
OpaqueNonClientView -> OpaqueBrowserFrameView

The latter two derive from NonClientFrameView via BrowserNonClientFrameView, which adds some extras.

I also had to modify the TabRenderer class to know how to drop its cache of tab background images when the theme changes since it uses different ones for Glass and non-Glass.

This change also fixes a few non-client flicker issues relating to window non-client activation by using more ScopedRedrawLocks. (Touches info_bubble.cc, window.cc)

Bugs fixed:
http://crbug.com/153
http://crbug.com/747
http://crbug.com/2371
http://crbug.com/3264
http://crbug.com/8234
Plumbing for http://crbug.com/8247

Design docs:
http://dev.chromium.org/developers/design-documents/views-windowing
http://dev.chromium.org/developers/design-documents/browser-window

Review URL: http://codereview.chromium.org/27317
------------------------------------------------------------------------

Comment 12 by venkataramana@chromium.org, Jul 16, 2009
 Issue 16901  has been merged into this issue.
Comment 13 by venkataramana@chromium.org, Jul 16, 2009
This still reproduces on ToT(r 20864)
Comment 14 by prog...@chromium.org, Jul 17, 2009
 Issue 16995  has been merged into this issue.
Comment 15 by Alexey.Kirichenko, Oct 19, 2009
Hi guys,

It seems this issue has the open state a long time.
I have the same problem with my custom dialog and hurray! I founded the solution how 
to  solve it. I've removed WS_SYSMENU style from dialog and use undocument event WM_TASKBUTTONMENU  = 0x313 to catch the click on application button in Taskbar. This 
takes me create my own system menu and display it when i click on caption bar or 
button on Taskbar.

This is you decision apply or not this solution.

Thanks a lot,
Alexey

Comment 16 by ben.at.chromium.org, Nov 15, 2009
I will try this out sometime in Mstone:5.
Labels: -Pri-1 -MagicBrowzr Pri-2 Mstone-5
Comment 17 by ben.at.chromium.org, Nov 18, 2009
I've been running Chrome in classic mode on Windows XP for 2 days now and haven't 
reproduced this. I think I'm going to resolve this as "Fixed" somehow.
Status: Fixed
Labels: Feature-Views
Sign in to add a comment

Powered by Google Project Hosting