sdy@ I saw something similar a few days ago and I think you were looking at it. Am I remembering correctly? I can't seem to find it now

Looks like  issue 778151  which was merged into  issue 761294 .

In which I am wondering that  issue 778151  and this issue are about the Omnibox and  issue 761294  is about the Tabstrip. But maybe/probably they have the same root cause.

This looks like the same issue, but it should be fixed in the current version of Chrome (62.0.3202.75, released in the last day or so). Are you sure that the version you submitted the bug with is the same one where you saw the bug? If so, let me know — and if you could provide a screen recording showing the content of chrome://version (which has some extra information) and demonstrate the bug, that would be super helpful.

I’m going to *tentatively* close this as a dupe, but if it’s still happening for you on the current stable then I’ll reopen.

While this has not happened for about 2 weeks now, it just appeared again. My Chrome is up to date: "Google Chrome is up to date Version 62.0.3202.89 (Official Build) (64-bit)"

Deleted: Screen Shot 2017-11-08 at 18.58.41.PNG 92.6 KB

	Screen Shot 2017-11-08 at 18.58.41.PNG 92.6 KB View Download

sdy@: is this the same issue like  issue 781815 , since this is still reproducible in latest Stable?

Hmm, OK. Is there anything else you can tell about when this happens? Does it only happen after Chrome's been running for a while, or can you relaunch and make it happen right away? Unfortunately I haven't had any luck so far. A screen recording showing you reproducing the issue would be super helpful.

 Issue 781815  has been merged into this issue.

mehmet@: Agreed!

I forgot to attach a screen recording of me failing to reproduce this bug to the other issue. I'm not following these exact repro steps, but suffice it to say I failed equally well at triggering it by switching tabs :(.

Deleted: crbug_781815_no_repro.mp4 5.7 MB

	crbug_781815_no_repro.mp4 5.7 MB View Download

Sorry, I forgot to record the system and browser "credentials", but I did think of showing what extensions I have active.

Filmed with my phone so I could zoom in on appropriate parts of the screen.

Deleted: grey-bar-after-fullscreen.MOV 6.3 MB

grey-bar-after-fullscreen.MOV 6.3 MB Download

You can see lots of recent user reports of this in Chrome discussion forum.

Any errors details you would like to know from users?

https://productforums.google.com/forum/#!topicsearchin/chrome/obscured$20category$3A(mac)%7Csort:date
https://productforums.google.com/forum/#!topicsearchin/chrome/bar$20address$20category$3A(mac)%7Csort:date
https://productforums.google.com/forum/#!topicsearchin/chrome/grey$20address$20category$3A(mac)%7Csort:date
https://productforums.google.com/forum/#!topicsearchin/chrome/grey$20covering$20category$3A(mac)%7Csort:date

Is this info important?

https://productforums.google.com/forum/#!topic/chrome/4pdg7upJWnE

An interesting fact: 
This only happens when I use chrome while my external monitors (dell, vga to thunderbolt) plugged in.

On Monday December 11 2017 02:35:12 sarj… via monorail wrote:

Yes. That's the exact same issue I'm facing with OS X 10.9 on a 3 year older MBP with a much less capable GPU: see https://bugs.chromium.org/p/chromium/issues/detail?id=781815

I don't know if I have to be relieved that this is thus not due to running an older OS or hardware, or not.

I too use an external monitor connected via Thunderbolt and will make note to verify if that has any influence.

A relevant tidbit: I started a Chrome copy from the terminal with `--user-data-dir=$TMPDIR/TempChromeProfile` to run independently from my usual browser "instance" and start with a clean set of factory preferences, no extensions etc.
The issue went away with that, so it could be due to
- personal "regular" configuration choices
- interference from one of my extensions
- "experiments" (chrome://flags) I activated or disabled
- accumulated "crud" in the profile directory that doesn't really cover any of the above. IOW, the sort of argument that makes people say you should always do a clean upgrade.


Next step will be to add at least the active extensions one by one, idem for the chrome://flags settings. Is there a way to export the list of extensions and/or the list of changes to the "experiments" to make that process a bit easier?

R.

I'm also experiencing this problem on a Mid 2012 MacBook Pro running OS X 10.11.6 (15G18013) and Chrome Version 63.0.3239.108 (Official Build) (64-bit). 

Even in Incognito Mode without extensions, I can reproduce it by just entering and exiting full screen on a YouTube video.

I've attached screenshots from before and after clicking fullscreen.

Deleted: Screen Shot 2017-12-17 at 6.57.04 PM.png 106 KB

	Screen Shot 2017-12-17 at 6.57.04 PM.png 106 KB View Download

Deleted: Screen Shot 2017-12-17 at 6.57.10 PM.png 98.9 KB

	Screen Shot 2017-12-17 at 6.57.10 PM.png 98.9 KB View Download

This can be reproduced reliably on my iMac (Yosemite) with an external monitor. On either monitor open a page with a video player. Play the video, go to full screen mode, exit full screen mode. Omnibar will be obscured. Happens every time. 

I'm also experiencing this problem on MAC air OS 10.9.5.

Deleted: 螢幕快照 2017-12-24 上午10.58.15.png 39.0 KB

	螢幕快照 2017-12-24 上午10.58.15.png 39.0 KB View Download

Same issue here with Chrome Version 63.0.3239.108 (Official Build) (64-bit)
on an MBP running OSX 10.11.6. Single 27" Dell external monitor hooked up. 

Machine specs: 
MBP, 15" Late 2013
Graphics: Intel Iris Pro 1536 MB
CPU: 2GHz Core i7
Memory: 8 GB 1600 MHz DDR3

This happens consistently when exiting a full screened video, primarily youtube, but also vimeo and virtually every other video player on the web. Even on an empty chrome profile, with no extensions or any other additions. 

When 2 profiles are running simultaneously, they are not both affected at the same time. As in, if I full screen a video in one profile, exit, I will have the gray bar in the current instance but the other will be unaffected unless I perform the same action there as well.

I can provide any other specs or details needed. 

Another interesting observation. Even if a window has only one tab, and Omnibar is obscured, dragging the tab will cause the Omnibar to be refreshed and it will be normal again. I presume this is because grabbing and dragging the tab causes a new window to be created "around" the tab, which has a properly displayed omnibar. 
So, if nothing else, this is a way to fix an obscured omnibar.

joec0… via monorail wrote on 20171231::19:57:43 re: " Issue 779082  in chromium: Graphics error: URL address bar hidden"

Sadly this doesn't work for me, or rather, it's not enough to drag a tab out of an affected window to a new one and then back into the affected window. Even if it's the tab that caused the issue in the first place. Nor if the tab was created in an unaffected window.

No, the original window cannot be "fixed" by putting a repaired tab back
into it. But you can drag all the tabs to a new or unobscured window.

 Issue 798217  has been merged into this issue.

Re: Comment 22. Dragging a tab to restore the omnibar only works if there is more than one chrome window or more than one tab on the obscured window.

Just here to mention this bug effects me and is getting old.

Thanks for the information, all. I'm working on this now. As I understand it, the issue only shows up when both of these conditions are met:

- macOS 10.11 and older.
- More than one monitor connected.

If anyone has seen it under different conditions, let me know.

I believe this will only happen if you have "Displays have separate Spaces" turned *off* in System Preferences. Does that match everyone's experience?

I only have one monitor and get this problem frequently. I've never used a
2nd monitor. I am running 10.9.5 on an imac mid-2011


*- Mike Weston*

Worship and Executive Pastor
Web: *www.northlakeonline.org* <http://www.northlakeonline.org>
Blog: *www.* <http://goog_931769389>*worshipmatters.net*
<http://worshipmatters.net>

Posted this on the help forum but thought it might help here too.  
Same issue since 11/2017. Can confirm, no theme, multiple monitors and it happened coming out of a fullscreen video I was watching on Adobe's site, also I had downloaded two items previously so the download bar was active and covering the video but I didn't close it. As soon as the fullscreen was exited the grey bar appeared. Also, it only appears on the browser I was watching the full-screen video on. I have 3 other chrome windows open (1 on the same monitor and 2 on another) the others are fine. I can add tabs, close tabs and even move the chrome window. Hope there is a solution soon. 

d… via monorail wrote on 20180102::18:55:43 re: " Issue 779082  in chromium: Graphics error: URL address bar hidden"

FWIW

I had noticed earlier that a secondary session launched with the --user-data-dir=/path/to/temp.profile.dir appears to be immune (not sure about the option name ATM). That's on 10.9.5, a MacBookPro8.1 with an external monitor connected via Thunderbolt.

Yesterday evening I started cloning my chrome://flags settings from the main session one by one, and then the active extensions and finally I connected to my google sync account.

I still cannot reproduce the issue in that secondary session with the clean profile dir but until now I have only tried with a single window open.
I did notice other transient glitches like audio playing through the wrong (internal) output device, or the whole window going into fullscreen mode instead of just the video.

I plan to try with multiple windows open later today, but also to open a guest account window in my main session to see if that one is afflicted too.

R

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

commit 1b761b8d95af216fbd403262ac001ab362e7a6b3
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Jan 03 19:24:31 2018

Fix strip which appears over the toolbar on exiting immersive fullscreen.

This regressed in r492972 (switch to a custom window frame view class).

When not using NSWindowStyleMaskFullSizeContentView (macOS <10.12, but
it can probably be turned on back to 10.10), certain circumstances
caused the tab strip background view to partially cover up the toolbar.
The most reliable way to reproduce it, for me, is:

- Be running macOS 10.11 or older.
- Have multiple monitors connected.
- Turn off "Displays have separate Spaces" in System Preferences.
- Enter web content fullscreen (e.g. on YouTube).
- Exit fullscreen by pressing Esc.

Three things came together to make this happen:

1. |-[FramedBrowserWindow browserFrameViewPaintHeight]| returned a
   hard-coded value when not using FullSizeContentView. I believe it
   used to represent the height of the tab strip but no longer does, and
   I believe it was just kept out of caution when the full size content
   view path was added, but it's bigger than it needs to be and makes
   the tab strip background view slightly larger than necessary. (This
   value originally appeared in r40677).

2. |-[TabWindowController
   insertTabStripBackgroundViewIntoWindow:titleBar:]| explicitly
   inserted the background view behind all other views.

3. The immersive fullscreen path, which is only taken when multiple
   monitors are connected and "Displays have separate Spaces" is turned
   off (see |-[BrowserWindowController enterWebContentFullscreen]|)
   inserts the content view behind all other views on exiting fullscreen
   (see |-[BrowserWindowController
   moveViewsForImmersiveFullscreen:regularWindow:fullscreenWindow:]|),
   which means that it's now behind the tab strip background view.

I'm fixing this with three changes:

1. Get rid of the special value in |-browserFrameViewPaintHeight| and
   return |chrome::kTabStripHeight| in both cases.

2. Hide the |visualEffectView_|/|tabStripBackgroundView_| in fullscreen
   always, not just when using FullSizeContentView — othersise, it can be seen
   visible on top of the content in fullscreen.

3. When setting up a window, insert the tab strip background view
   normally instead of behind its siblings. It just made these bugs
   harder to find (the strip would have appeared all the time,
   otherwise).

Bug:  779082 
Change-Id: Id9536dc6ff8593b3e7e2b3f38bbf9149418d0ac6
Reviewed-on: https://chromium-review.googlesource.com/848641
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526766}
[modify] https://crrev.com/1b761b8d95af216fbd403262ac001ab362e7a6b3/chrome/browser/ui/cocoa/framed_browser_window.mm
[modify] https://crrev.com/1b761b8d95af216fbd403262ac001ab362e7a6b3/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

This change should be in tomorrow's Canary. If anyone on the bug wants to give it a shot and see if you can break it (tomorrow), go ahead :). If things look OK, I'll try for an M64 merge.

bugdro… via monorail wrote on 20180103::11:25:23 re: " Issue 779082  in chromium: Graphics error: URL address bar hidden"

I could wait until tomorrow, but let me ask already if this does NOT mean that all screen are going to be blacked out when a window is in fullscreen mode on (evidently) one of the screens attached? I know that would be the native full screen behaviour in the "Spaces do NOT have separate screens" mode, but it's not hard at all to avoid this inexplicable choice by rolling one's own fullscreen mode.

R.

re: Comment 34 - Great! Thanks.
re: Comment 35 I'm not sure exactly what this is asking, but I certainly don't want to see a regression back to all screens being blacked out when one goes to full screen. It took a long time to get that rectified a few releases ago. It works great in that respect now, this Omnibar bug aside. 

Re. c#35, Yep, Chrome still has a hand-rolled full screen implementation for this case, and this change shouldn't affect it.

Currently MacOS 10.11 or older version is not available with HYD Chrome-TE team. Requesting someone from MTV team to verify the fix for this issue.

Thanks!

Hi 

Still the same issue
chrome version: 63.0.3239.84

after full-screen, the search bar is hidden

Deleted: 螢幕快照 2018-01-05 下午8.43.45.png 103 KB

	螢幕快照 2018-01-05 下午8.43.45.png 103 KB View Download

pinruchen23@gmail.com: Can you please try it with latest Canary from https://www.google.com/chrome/browser/canary.html ? It should be fixed there.

On Friday January 05 2018 06:35:34 meh… via monorail wrote:

I don't think this is progress ...

1- the first couple of times I tried to put a video full-screen there was some flickering, the menubar was hidden, and then the window reappeared, completely empty, but no video in sight. A bit as if the fullscreen overlay window hadn't been mapped.
2- After restarting Canary with reopening of the session consisting of a youtube page, the window opened in native fullscreen mode.
3. This seems to happen systematically when restarting a session containing a youtube window on a video I watched fullscreen (NB: I never exit with a video still fullscreen or even still playing). This may be the result of some action from youtube, but the browser should never accept to execute the request without confirmation from the user.

R.

Just tried Canary on an iMac running Yosemite 10.10.5 (14F2511) with an
extension monitor. Seems to have fixed the omnibar problem. Have tried a
number of different combinations of video players, one screen maxed, both
screens maxed. Everything seems to be working fine. I'll continue using
Canary just to see if there are any other issues.

Thanks for this!!

Joe Cascio

Re. #42, how about this bug? Canary is several versions ahead of stable Chrome, so there tend to be a number of independent changes/bugs in play at any given time.

Would you mind filing new bugs for these issues?

Re. #43, thanks for verifying!

On Friday January 05 2018 09:21:37 s… via monorail wrote:

I can't reproduce it in the current canary. But as I said in an earlier comment, I cannot reproduce it either with the current release version running from a different profile. I tried copying my normal Chrome profile directory over into Canary's, and that seems to have caused all kinds of mishap - but not this issue.

I was planning to do that at least for the unwanted fullscreen mode. I've noticed that one in the current version too so it's probably not a new issue.

R.

I'm seeing this issue.  iMac 5K running OSX 10.10.5.  Chrome Version 63.0.3239.132 (Official Build) (64-bit).  Can be reproduced by maximizing a video and then returning. The gray bar mostly obscures the URL bar for all tabs in that window.  Moving a tab to a new window fixes the issue for that one moved tabs, but other tabs in the original window remain obscured.

cwerby@: It's fixed on canary, but could be a few weeks before the it makes it to stable Chrome.

Release team: Thoughts on a merge (1b761b8d95af216fbd403262ac001ab362e7a6b3)? This broke in M62 and it would be nice to have it fixed in M64. I think it's a fairly safe change.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+ Abdul for M64 merge review.

thanks for the fix sdy@! My usual recommendation is to wait until M65, since this has been broken since M62 and we're only 2 weeks away from stable. However, the fix doesn't seem too complicated and seems like this is affecting a large number of users (36 stars). I'm supportive of this merge.

Shrike: can you please confirm if you're ok to take this merge as well?

Approving merge for M64. Branch:3282

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

commit e5e0800876fb452f690eb349b2fb1a77eccb6b54
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Jan 09 23:56:51 2018

Fix strip which appears over the toolbar on exiting immersive fullscreen.

This regressed in r492972 (switch to a custom window frame view class).

When not using NSWindowStyleMaskFullSizeContentView (macOS <10.12, but
it can probably be turned on back to 10.10), certain circumstances
caused the tab strip background view to partially cover up the toolbar.
The most reliable way to reproduce it, for me, is:

- Be running macOS 10.11 or older.
- Have multiple monitors connected.
- Turn off "Displays have separate Spaces" in System Preferences.
- Enter web content fullscreen (e.g. on YouTube).
- Exit fullscreen by pressing Esc.

Three things came together to make this happen:

1. |-[FramedBrowserWindow browserFrameViewPaintHeight]| returned a
   hard-coded value when not using FullSizeContentView. I believe it
   used to represent the height of the tab strip but no longer does, and
   I believe it was just kept out of caution when the full size content
   view path was added, but it's bigger than it needs to be and makes
   the tab strip background view slightly larger than necessary. (This
   value originally appeared in r40677).

2. |-[TabWindowController
   insertTabStripBackgroundViewIntoWindow:titleBar:]| explicitly
   inserted the background view behind all other views.

3. The immersive fullscreen path, which is only taken when multiple
   monitors are connected and "Displays have separate Spaces" is turned
   off (see |-[BrowserWindowController enterWebContentFullscreen]|)
   inserts the content view behind all other views on exiting fullscreen
   (see |-[BrowserWindowController
   moveViewsForImmersiveFullscreen:regularWindow:fullscreenWindow:]|),
   which means that it's now behind the tab strip background view.

I'm fixing this with three changes:

1. Get rid of the special value in |-browserFrameViewPaintHeight| and
   return |chrome::kTabStripHeight| in both cases.

2. Hide the |visualEffectView_|/|tabStripBackgroundView_| in fullscreen
   always, not just when using FullSizeContentView — othersise, it can be seen
   visible on top of the content in fullscreen.

3. When setting up a window, insert the tab strip background view
   normally instead of behind its siblings. It just made these bugs
   harder to find (the strip would have appeared all the time,
   otherwise).

TBR=sdy@chromium.org

(cherry picked from commit 1b761b8d95af216fbd403262ac001ab362e7a6b3)

Bug:  779082 
Change-Id: Id9536dc6ff8593b3e7e2b3f38bbf9149418d0ac6
Reviewed-on: https://chromium-review.googlesource.com/848641
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#526766}
Reviewed-on: https://chromium-review.googlesource.com/858316
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#472}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/e5e0800876fb452f690eb349b2fb1a77eccb6b54/chrome/browser/ui/cocoa/framed_browser_window.mm
[modify] https://crrev.com/e5e0800876fb452f690eb349b2fb1a77eccb6b54/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

Side note: it only affects the Chromium window in which the full-screen was initiated; so a temporary workaround, for now, is to open a new window (Cmd-n) or shift-click a link to force the video you wish to watch to be rendered in a separate window. That window can safely be full-screened to watch the video, returned to regular size (it will have a grey bar), leaving your main window(s) and their respective tabs unperturbed. This saves having to Cmd-q-q and relaunch (I have dozens of tabs open permanently, so restarts are expensive)

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

commit d16499abeaf7b124eee7e5f396765dfb0c4ed793
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Jan 10 21:52:33 2018

Revert "Fix strip which appears over the toolbar on exiting immersive fullscreen."

This reverts commit e5e0800876fb452f690eb349b2fb1a77eccb6b54.

Reason for revert: Regression. Now, entering immersive fullscreen, exiting, and then entering AppKit full screen (with the zoom button) creates a visible "grey bar".

Original change's description:
> Fix strip which appears over the toolbar on exiting immersive fullscreen.
> 
> This regressed in r492972 (switch to a custom window frame view class).
> 
> When not using NSWindowStyleMaskFullSizeContentView (macOS <10.12, but
> it can probably be turned on back to 10.10), certain circumstances
> caused the tab strip background view to partially cover up the toolbar.
> The most reliable way to reproduce it, for me, is:
> 
> - Be running macOS 10.11 or older.
> - Have multiple monitors connected.
> - Turn off "Displays have separate Spaces" in System Preferences.
> - Enter web content fullscreen (e.g. on YouTube).
> - Exit fullscreen by pressing Esc.
> 
> Three things came together to make this happen:
> 
> 1. |-[FramedBrowserWindow browserFrameViewPaintHeight]| returned a
>    hard-coded value when not using FullSizeContentView. I believe it
>    used to represent the height of the tab strip but no longer does, and
>    I believe it was just kept out of caution when the full size content
>    view path was added, but it's bigger than it needs to be and makes
>    the tab strip background view slightly larger than necessary. (This
>    value originally appeared in r40677).
> 
> 2. |-[TabWindowController
>    insertTabStripBackgroundViewIntoWindow:titleBar:]| explicitly
>    inserted the background view behind all other views.
> 
> 3. The immersive fullscreen path, which is only taken when multiple
>    monitors are connected and "Displays have separate Spaces" is turned
>    off (see |-[BrowserWindowController enterWebContentFullscreen]|)
>    inserts the content view behind all other views on exiting fullscreen
>    (see |-[BrowserWindowController
>    moveViewsForImmersiveFullscreen:regularWindow:fullscreenWindow:]|),
>    which means that it's now behind the tab strip background view.
> 
> I'm fixing this with three changes:
> 
> 1. Get rid of the special value in |-browserFrameViewPaintHeight| and
>    return |chrome::kTabStripHeight| in both cases.
> 
> 2. Hide the |visualEffectView_|/|tabStripBackgroundView_| in fullscreen
>    always, not just when using FullSizeContentView — othersise, it can be seen
>    visible on top of the content in fullscreen.
> 
> 3. When setting up a window, insert the tab strip background view
>    normally instead of behind its siblings. It just made these bugs
>    harder to find (the strip would have appeared all the time,
>    otherwise).
> 
> TBR=sdy@chromium.org
> 
> (cherry picked from commit 1b761b8d95af216fbd403262ac001ab362e7a6b3)
> 
> Bug:  779082 
> Change-Id: Id9536dc6ff8593b3e7e2b3f38bbf9149418d0ac6
> Reviewed-on: https://chromium-review.googlesource.com/848641
> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
> Commit-Queue: Sidney San Martín <sdy@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#526766}
> Reviewed-on: https://chromium-review.googlesource.com/858316
> Reviewed-by: Sidney San Martín <sdy@chromium.org>
> Cr-Commit-Position: refs/branch-heads/3282@{#472}
> Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}

TBR=ellyjones@chromium.org,sdy@chromium.org

Change-Id: I4dbb45cddcfe52edcd5173c3b15543810d9aaa95
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  779082 
Reviewed-on: https://chromium-review.googlesource.com/860479
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#481}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/d16499abeaf7b124eee7e5f396765dfb0c4ed793/chrome/browser/ui/cocoa/framed_browser_window.mm
[modify] https://crrev.com/d16499abeaf7b124eee7e5f396765dfb0c4ed793/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

Thank you Sidney for taking a look and reverting the change to avoid new regressions in M64.

manoranj… via monorail wrote on 20180110::16:27:28 re: " Issue 779082  in chromium: Graphics error: URL address bar hidden"


This is annoying. I NEVER use the "AppKit fullscreen" (native fullscreen) if I can avoid it, because it disables all my screens except the one with the fullscreen application.

2 possible workarounds:

- provide the fix as an "experiment", disabled by default but still accessible to those of us who are concerned by the original issue. Should also help fine-tuning the fix in the wild, in the otherwise stable browser version.

- don't use the native fullscreen at all, as an option, but instead use the home-rolled traditional fullscreen for everything. This may mean you'll have to disable the fullscreen titlebar widget, but that's a trivial task.

Is there any doubt the 2nd option would have my vote and full support?

R.

This issue isn't consistently reproducible on my system but it does happen. And now getting reports of other users at my company having the issue.

My system info:
Chrome Stable - Version 63.0.3239.132 (Official Build) (64-bit)
Model Name:	MacBook Pro
Model Identifier:	MacBookPro11,1
System Version:	OS X 10.11.6 (15G17023)
Kernel Version:	Darwin 15.6.0

This happens on my system without fail, every time I exit fullscreen on an embedded video: youtube, vimeo, or other player. It's very disruptive of my normal workflow.

OSX 10.11.6
Multiple displays
Chrome up to date

I read the thread thus far. Is it correct that this has been fixed, and will be merged soon, into the version 64 update, without reverting to older fullscreen behavior, where all other windows are hidden?

Re. c#60 and c#61: This has been fixed in Chrome Canary, but the change hasn't made it to stable.

Re. #58, is there a reason why the default setting for "Displays have separate spaces" doesn't work for you, just out of curiosity? We have no immediate plans to ditch the custom fullscreen code, but I'd be interested in understanding why it's helpful.

Re. c#55, another workaround is to create a new tab, then click the first tab in the window, then shift+click the last tab that *isn't* the new tab, then drag all of the other tabs out into a new window together.

Not #58, but I never turn on 'Displays Have Separate Spaces' because I use TotalSpaces2 to manage my inter-desktop navigation. I'd rather switch to Linux than give up TS functionality. Mission Control / Spaces is a mess.

s… via monorail wrote on 20180116::09:13:12 re: " Issue 779082  in chromium: Graphics error: URL address bar hidden"

Simple: it depends on your personal way of organising your desktop space. If you use spatial organisation where each screen receives a particular class of apps/windows and use spaces/desktops for different tasks it can be extremely confusing if all screens don't switch space/desktop at once. And cumbersome, because you need to remember to take care that the Space-switching keyboard shortcut affects the intended screen (I presume that means moving the mouse, possibly even activating a window).

As an example: I have a 13" non-retina MBP with a 22" external screen that has the menubar. The "internal" screen is only 800px or so high, so quickly feels cramped and thus gets the smaller, less important windows (or those that don't need to be huge, like the email client - email compositor windows open on the main screen). Not having a menubar is a boon here.

Space 1: coding; the small screen will typically hold documentation windows, a fallback terminal and a log viewer
Space 2: email & general internet stuff
Space 3: reserved for VMs and VNC clients (here the smaller screen will act as a window on the host)

I haven't always had the possibility to use virtual desktops (spaces) but have been using multi-head set-ups this way since the early 90s.

To me the question is more how people can work with "displays have separate spaces", esp. if you also use multi-screen set-ups running other OSes. I'm not aware that a similar option exists elsewhere.

(I do realise that my earliest multi-head experience did involve something similar: 1 screen per video board, and 1 X server per screen because A/UX didn't allow anything else :) )

R

We are also experiencing the hidden address bar on our iMac when using Chrome though it does not happen all the time. Do we have a fix yet? This is very annoying.

Deleted: Screen Shot 2018-01-19 at 6.49.59 AM.png 380 KB

	Screen Shot 2018-01-19 at 6.49.59 AM.png 380 KB View Download

If you read the thread, you'll see it's fixed in the next stable release of Chrome. :)

Sdy@,
Friendly ping to get an update on this issue as it is marked as stable blocker.
Thanks..!

It turns out that  issue 800942  is a separate issue, not a regression, which means that the current fix is still OK. I'm going to re-merge to 3282 (i.e. undo the revert) so that it's available in M64 in case there's a respin.

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

commit f8e519c1a446343d0f8200aa8817b2a9a512180f
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Jan 24 04:41:37 2018

Reland "Fix strip which appears over the toolbar on exiting immersive fullscreen."

This is a reland of e5e0800876fb452f690eb349b2fb1a77eccb6b54.

Original change's description:
> Fix strip which appears over the toolbar on exiting immersive fullscreen.
> 
> This regressed in r492972 (switch to a custom window frame view class).
> 
> When not using NSWindowStyleMaskFullSizeContentView (macOS <10.12, but
> it can probably be turned on back to 10.10), certain circumstances
> caused the tab strip background view to partially cover up the toolbar.
> The most reliable way to reproduce it, for me, is:
> 
> - Be running macOS 10.11 or older.
> - Have multiple monitors connected.
> - Turn off "Displays have separate Spaces" in System Preferences.
> - Enter web content fullscreen (e.g. on YouTube).
> - Exit fullscreen by pressing Esc.
> 
> Three things came together to make this happen:
> 
> 1. |-[FramedBrowserWindow browserFrameViewPaintHeight]| returned a
>    hard-coded value when not using FullSizeContentView. I believe it
>    used to represent the height of the tab strip but no longer does, and
>    I believe it was just kept out of caution when the full size content
>    view path was added, but it's bigger than it needs to be and makes
>    the tab strip background view slightly larger than necessary. (This
>    value originally appeared in r40677).
> 
> 2. |-[TabWindowController
>    insertTabStripBackgroundViewIntoWindow:titleBar:]| explicitly
>    inserted the background view behind all other views.
> 
> 3. The immersive fullscreen path, which is only taken when multiple
>    monitors are connected and "Displays have separate Spaces" is turned
>    off (see |-[BrowserWindowController enterWebContentFullscreen]|)
>    inserts the content view behind all other views on exiting fullscreen
>    (see |-[BrowserWindowController
>    moveViewsForImmersiveFullscreen:regularWindow:fullscreenWindow:]|),
>    which means that it's now behind the tab strip background view.
> 
> I'm fixing this with three changes:
> 
> 1. Get rid of the special value in |-browserFrameViewPaintHeight| and
>    return |chrome::kTabStripHeight| in both cases.
> 
> 2. Hide the |visualEffectView_|/|tabStripBackgroundView_| in fullscreen
>    always, not just when using FullSizeContentView — othersise, it can be seen
>    visible on top of the content in fullscreen.
> 
> 3. When setting up a window, insert the tab strip background view
>    normally instead of behind its siblings. It just made these bugs
>    harder to find (the strip would have appeared all the time,
>    otherwise).
> 
> TBR=sdy@chromium.org
> 
> (cherry picked from commit 1b761b8d95af216fbd403262ac001ab362e7a6b3)
> 
> Bug:  779082 
> Change-Id: Id9536dc6ff8593b3e7e2b3f38bbf9149418d0ac6
> Reviewed-on: https://chromium-review.googlesource.com/848641
> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
> Commit-Queue: Sidney San Martín <sdy@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#526766}
> Reviewed-on: https://chromium-review.googlesource.com/858316
> Reviewed-by: Sidney San Martín <sdy@chromium.org>
> Cr-Commit-Position: refs/branch-heads/3282@{#472}
> Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}

Bug:  779082 
Change-Id: Icc980357f0008056de745d28083558a59cb2865e
Reviewed-on: https://chromium-review.googlesource.com/882266
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#591}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/f8e519c1a446343d0f8200aa8817b2a9a512180f/chrome/browser/ui/cocoa/framed_browser_window.mm
[modify] https://crrev.com/f8e519c1a446343d0f8200aa8817b2a9a512180f/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

 Issue 806132  has been merged into this issue.

Is there any merge needed for M65?

c#73: Nope, this landed in M65 originally. There's one M65 merge under  issue 800942 .

Wait, apparently I didn't land that? Checking it out now (but will reply on the other crbug).

Thank you sdy@. 

Per https://bugs.chromium.org/p/chromium/issues/detail?id=800942&desc=2#c5, we're going to wait for M66. So no merge is needed there as well, right?

Oh, right. That ended up being fixed by another change which will be in M66. So, no M65 merges. Sorry for the spam!

No worries, Thank you for confirmation.

Still happening for me with an updated chrome.

Still happening for me, too. Just did the update and relaunch.

It should be fixed in any version of Chrome greater than or equal to 64.0.3282.121, which will either be:

- 64.0.3282.[x >= 121]
- 65.x.x.x

For someone who relies on a stable version, should I download the .121? Or must I wait for the 65 release?

To get .121 instead of .119 I'll have to download a new beta browser?

I’d recommend waiting — I just meant that it’s expected that this isn’t fixed in the current stable, and was sharing how to tell if you have a version with the fix (in the future, not right now).

Thank you.

With dev release on mac I have -
Version 65.0.3325.18 (Official Build) dev (64-bit)
First version where the browser bar cover glitch is finally fixed (FYI)

The current Beta doesn't have the fix

Unable to reproduce the issue on Mac 10.13.2 with reported chrome #62.0.3202.75

Steps followed:
1. Turned off "Displays have separate Spaces" in System Preferences.
2. Dragged chrome to external monitor - HP Z24i
3. Played youtube for sometime in fullscreen mode and switched between tabs for a while

Observation:
URL Address bar is seen as expected. No half grey area is seen


Note: Since the issue is reported on lower versions of Mac which are not available with TE, requesting MTV team to look into this issue for fix verification.


Thank You... 

I have verified this fix in 64.0.3282.140.

When will this be released for OSX 10.10.5? 
When I run Chrome it says I am up-to-date at 64.0.3282.119.

sdy@, thank you so much for verifying the fix.

The bug still appears in older (Yosemite, El Capitan) versions of the Mac OS. I too have the latest Chrome version and the bug persists on OS 10.11.6.

A fix for this rolled out yesterday afternoon. Please update your Chrome Stable version to 64.0.3282.140 to receive the fix. Thank you everyone for your input and thanks sdy@ for the fix! Please let us know if any issues.

Thanks! The problem was easily reproducible on my El Cap 10.11.6, multiple displays, 'Displays Have Separate Spaces' is OFF.

It works now. There is no occlusion of the URL bar when returning from full screeen mode.

Just updated my Chrome to 64.0.3282.140 (Official Build) (64-bit) I have tested on Youtube and Vimeo a few times and so far it works! Thanks so much to the team that worked so hard to fix this! It's so nice being able to see URL and the back and forward buttons again!  Thanks again~

I have Chrome Version 70.0.3538.67 (Official Build) (64-bit), MacOS 10.13.6, and this issue returns. There is no address bar when I maximize Chrome in fullscreen mode, then make a YouTube video fullscreen.