Can you reproduce it with latest Canary Build? 

https://www.google.de/chrome/browser/canary.html

Yes. I reproduced it using twitter homepage

See screenshots (ordered in the steps I used to reproduce)

1. Go to twitter homepage (not logged in)
2. Resize window down
3. Click on a link (I chose sports tab to most reliably reproduce)
4. Resize window larger
5. see that address bar is missing (along with some of the extensions at times)

It seems to not always happen, but it can most reliably be reproduced on https supported sites and clicking around on those sites while resizing the window

Deleted: canary-1.png 1.8 MB

	canary-1.png 1.8 MB View Download

Deleted: canary-2.png 770 KB

	canary-2.png 770 KB View Download

Deleted: canary-3.png 2.0 MB

	canary-3.png 2.0 MB View Download

Deleted: canary-4.png 716 KB

	canary-4.png 716 KB View Download

Deleted: canary-5.png 2.1 MB

	canary-5.png 2.1 MB View Download

Thank you for providing more feedback. Adding requester "mehmet@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

jmilis: Thanks a lot for checking it in Canary. Can you please attach a screencast from the steps to reproduce the problem? Unfortunately I can't reproduce it on my MacBook Air 11".

Thanks in advance.

Thanks for reporting, jmills!

It looks to me like this might not be the latest canary (note the yellow "update" icon in the right of the toolbar)

Would it be possible to paste the version number from chrome://version

Version: 61.0.3162.0 (Official Build) canary (64-bit)

The yellow check mark is due to one of my extensions not working in Canary. See attached for screencast

Deleted: chrome-bug-480.mov 6.1 MB

chrome-bug-480.mov 6.1 MB Download

Thanks, that's really helpful!

I can repro the part where the page actions disappear by loading up on extensions. No luck yet with the Omnibox.

I also can repro the part with the gap between the page action buttons and the Hamburger Menu button. Also no luck yet with the disappearance of the Omnibox.

 Issue 755751  has been merged into this issue.

 Issue 761122  has been merged into this issue.

Upping the priority, since this is reproducible.

Looks like all these issues are coming from Mac OS 10.11.4( Issue 761122  as well). Don't have Mac OS 10.11.4 available to test and confirm this from the team here. Hence looping MTV team to check once from their end.


Note: I was unable to reproduce the issue on the latest MacBook Air OS 10.12.6, chrome canary version:63.0.3213.3. 

 Issue 766440  has been merged into this issue.

Re: page actions:

It turns out this one is NOT a regression from the toolbar RTL work (just checked in 56).

Re: omnibox

Still no repro

I was just able to repro and captured screenshots immediately before the refresh and immediately after.

A co-worker reports frequently encountering this issue as well.

Deleted: immediately-before.png 222 KB

	immediately-before.png 222 KB View Download

Deleted: immediately-after.png 220 KB

	immediately-after.png 220 KB View Download

ray.pawulich@cbsinteractive.com, - when you say "immediately before the refresh" what refresh are you referring to? What happens in between the two screenshots?

shrike@: see  Issue 766440  which got duped into this

FWIW I'll note that the omnibox wants to remain wide enough to display "https". If you make the window as narrow as possible and drag the omnibox's right edge to the left, you can make it so narrow that the "s" gets left out but when you release the mouse the omnibox resizes to the "https" width.

However, if you now widen the window and drag the omnibox's right edge as far as possible to the left, and then make the window as narrow as possible, the final omnibox width will only allow "http" to remain visible. The screenshot shows the omnibox in this state.

Interesting. For me, if I have seven or greater extension icons visible in the widest view, the omnibox seems to forget to reserve horizontal space for the "s" in "https" in the narrow view.

I don't typically adjust the size of the omnibox but perhaps the lost "s" indicates the conditions under which the issue can occur. Perhaps I can work around it by leaving only seven extensions icons visible.

re: c#17 - thank you lgrey@

It seems that the locationBar does not get removed from the view (I don't see any code that ever does that). That implies that either it's origin is something that positions it outside of its superview's bounds, or it has a width <= 0.

There are only a few places in toolbar_controller.mm that set the locationBar's frame. Of those, adjustLocationSizeBy:animate: is the only one that seems like it could be involved in this bug. I note that it does not sanity check the dX that's passed in, so a caller passing a bad dX could cause the locationBar to go to <= 0 width.

The only place that does not sanity check the dX it passes in is 
pinLocationBarBeforeBrowserActionsContainerAndAnimate:. It computes dX with:

    CGFloat rightEdge = NSMaxX([locationBar_ frame]);
    delta = NSMinX([browserActionsContainerView_ animationEndFrame]) -
            kButtonInset - rightEdge;

The delta computation assumes that NSMinX([browserActionsContainerView_ animationEndFrame]) is reasonable. If it's (0,0,0,0), for example, delta would resize the locationBar to less than 0.

In browser_actions_container_view.mm, -animationEndFrame says the following:

  if ([resizeAnimation_ isAnimating]) {
    NSRect endFrame = [[[[resizeAnimation_ viewAnimations] objectAtIndex:0]
        valueForKey:NSViewAnimationEndFrameKey] rectValue];
    return endFrame;
  } else {
    return [self frame];
  }

In the isAnimating case == YES case, the code assumes that [resizeAnimation_ viewAnimations] does not return nil. That seems like a reasonable assumption because it has already established that the view is animating, so it should have a viewAnimation. However, resizeAnimation_ is set to be non-blocking around line 63:

    [resizeAnimation_ setAnimationBlockingMode:NSAnimationNonblocking];

Imagining this animation being driven by some background thread, it seems like there could be a race condition between checking that the animation is running and asking for its viewAnimations, especially if the animation's start and end frame rects are the same (-resizeToWidth:animate: kicks off an animation even if there will be no net change). I can imagine the NSViewAnimation clearing out its animations upon completion.

I think it would be safer/better to say:

- (NSRect)animationEndFrame {
  NSValue* endFrameValue = [[[resizeAnimation_ viewAnimations] objectAtIndex:0]
                               valueForKey:NSViewAnimationEndFrameKey];

  return ([resizeAnimation_ isAnimating] && endFrameValue) ? [endFrameValue rectValue]
                                                           : [self frame];
}

shrike@ that logic checks out to me and might explain the intermittent nature, but I'm still puzzled re: why I can't repro at all, no matter how hard I try. Can you think of a good way to increase the chance of a race here to get a repro?

Looking at the docs it turns out NSAnimationNonblocking just means run on the main thread in a run loop that does not block user input :-/.

That said, the code is still making the assumption that [resizeAnimation_ viewAnimations] does not return nil. It's not clear to me that that is guaranteed to be true even if the animation is running, so maybe land the change as a speculative fix and see if it helps people who encounter this bug?

Issue 752125 has been merged into this issue.

After looking into it a bit, it seems like a sound assumption given the current code. |viewAnimations| stays populated after the animation ends (probably so it can be started again).

As an alternate speculative fix, I'm thinking about clipping the width in |adjustLocationSizeBy:animate:| to the min width. WDYT?

Thanks for checking on viewAnimations. Seems like clipping to min width is a good thing to try.

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

commit 12255d72df0ce59a0a17c218abacd9a99c98340f
Author: Leonard Grey <lgrey@chromium.org>
Date: Thu Sep 21 19:03:03 2017

[Mac] Clip location bar to minimum size

There's currently a very hard to reproduce bug that causes the omnibox
to disappear, typically after a refresh. One theory is that this is due
to the location bar being set to 0 or negative width from some bad
calculation or other.

This change clips the size to the minimum. Specifically, the delta is
clipped, rather than the final size, so that the origin can be correctly
adjusted for RTL.

Bug:  746944 
Change-Id: I4a1710f2ac87e70d4b19f88142c6b9fa73a3a0a8
Reviewed-on: https://chromium-review.googlesource.com/677228
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503524}
[modify] https://crrev.com/12255d72df0ce59a0a17c218abacd9a99c98340f/chrome/browser/ui/cocoa/toolbar/toolbar_controller.mm

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

commit 3617e109737030f3de09eaba3de0953f45f6fc4e
Author: Leonard Grey <lgrey@chromium.org>
Date: Fri Sep 22 14:40:27 2017

[Mac] Update browser actions container on frame resize

Currently, if the user has more browser actions than can fit in the
minimum width of the container and they refresh with the browser window
at minimum size, expanding the window doesn't restore overflow actions
to the expanded container.

This change ensures that the container recalculates which buttons
should be visible on frame change.

Bug:  746944 
Change-Id: I7c149da1ef268955142311dada4720af87ffc98f
Reviewed-on: https://chromium-review.googlesource.com/675838
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503734}
[modify] https://crrev.com/3617e109737030f3de09eaba3de0953f45f6fc4e/chrome/browser/ui/cocoa/app_menu/app_menu_controller.mm
[modify] https://crrev.com/3617e109737030f3de09eaba3de0953f45f6fc4e/chrome/browser/ui/cocoa/extensions/browser_actions_controller.mm

Just to update, I was able to reproduce the page action bug on Mac OS 10.12.6 using version: 63.0.3220.0(without CL from C#27,C#28) but this worked fine on the latest canary 63.0.3223.8(with CL from C#27,C#28)

I was unable to reproduce the no omnibox bug, hence unable to confirm the fix of that.

jmills@: Could you please check the omnibox disappearance bug on the latest canary and confirm if this still appears there from your end?

Removing the Needs-Bisect label as the issue is no more reproducible on latest canary #63.0.3225.0. Observed that resizing the window did not remove the address bar.

Requesting jmills@ to check the omnibox disappearance issue on the latest canary #63.0.3225.0 and confirm if this still appears there from your end?

Thanks...!!

I've gotten the search bar disappearing issue once yesterday and twice today (way higher occurrence rate than before). Did something change?

M63 is branching on this Thursday (10/12) and M63 beta promotion is coming very soon. Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP. Thank you.

Removing RBB since we have no way to repro this.

 Issue 785667  has been merged into this issue.

I started getting this issue again, in both chrome tabs in split-screen mode on mac os. Just wanted to ping this thread (I had this happen twice yesterday)

Which version of Chrome?

Version 62.0.3202.94 (Official Build) (64-bit)

It happened again on my main non-split-screen chrome window, which has plenty of room for the address bar at the top (this window was never resized)

Deleted: chrome_search_bar_disappeared.png 135 KB

	chrome_search_bar_disappeared.png 135 KB View Download

Hopefully this is fixed in M63, which will be released very soon. Please let us know if you continue to experience this problem after you've upgraded.

Sounds good, will do.

Is anyone still experiencing this issue?  The team thinks it has been fixed (in Chrome 63).

I have not experienced this issue in some time & believe it has been resolved.

Thanks for replying!  Closing.