fix flashing bottom gray bar when navigating away from NTP w/ unpinned bookmark bar

fix flashing bottom gray bar when navigating away from NTP w/ unpinned bookmark bar

cause:
- when NTP has unpinned bmb, the web contents takes up the remaining height of the tab contents area.
- when navigating away from NTP, unpinned bmb disappears, so the web contents take up the entire tab contents area, i.e. taller than when on NTP.
- this resize of web contents view causes a flashing bottom gray bar after the NTP contents are cleared and before the new page contents are completely painted.

fix is to prevent any resizing, and hence re-layout, of the new page contents:
- add a method to WebContentsDelegate to allow size specification for newly-created render views.
- WebContentsImpl calls this method when creating render views and updating their sizes.
- this prevents render views from being created at a default size only to be resized immediately.
- also added browser_tests for browser and content

BUG=264207
TEST=verify per bug rpt

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=219794

[kuan, 2013-08-03 00:25:55]

hi scott,

ptal at this approach to fix the mentioned bug.

for the record (in case this approach is not acceptable), i arrived at it after
the following attempts that yielded inconsistent results or undesirable side
effects:

1) implement WebContentsObserver::AboutToNavigateRenderView like i've done for
WebContentsObserver::RenderViewCreated in this cl: gray bar still appears
sometimes.

2) in BrowserView::ActiveTabChanged, force ContentsContainer::Layout to make the
WebContentsView and RenderWidgetHostView taller but keep the active WebView
same: 1st tab still has gray bar, but subsequent tabs are ok.

3) to try to fix result of (2), i create a simple views::View parent for
ContentsContainer's active WebView; this parent fills the space below the
unpinned bmb but the active WebView's height is same as ContentsContainer's, so
that there's never any resizing of WebView, WebContentsView or
RenderWidgetViewHost: gray bar completely goes away, but then i can't scroll to
the bottom of the ntp page because of the mismatched sizes between the parent
and the WebView.

[sky, 2013-08-05 16:54:20]

> update the size of the WebContents view and the render view
> host for the new page contents to the new taller size
> immediately after the render view has been created, so that
> there's no relayout and resizing. 

Can you create the WebContents at the right size? Wouldn't that mean there is no
jank, especially if the resize is async?

[kuan, 2013-08-05 17:03:48]

On 2013/08/05 16:54:20, sky wrote:
> > update the size of the WebContents view and the render view
> > host for the new page contents to the new taller size
> > immediately after the render view has been created, so that
> > there's no relayout and resizing. 
> 
> Can you create the WebContents at the right size? Wouldn't that mean there is
no
> jank, especially if the resize is async?

when WebContentsImpl::CreateRenderViewForRenderManager creates the
RenderViewHost, it also automatically sets its size to that of WebContentsView,
which is the shorter size at that time.  there's no way to hook into this, so i
found the earliest callback possible, which is RenderViewCreated.  based on
review feedback on previous cl (from jam@) about adding new interface to
WebContents, i don't think that would be acceptable here either.

[sky, 2013-08-05 17:45:40]

Can you resize the WebContentsView first then? Wouldn't that mean
newly created ones get the right size?

  -Scott

On Mon, Aug 5, 2013 at 10:03 AM,  <[email protected]> wrote:
> On 2013/08/05 16:54:20, sky wrote:
>>
>> > update the size of the WebContents view and the render view
>> > host for the new page contents to the new taller size
>> > immediately after the render view has been created, so that
>> > there's no relayout and resizing.
>
>
>> Can you create the WebContents at the right size? Wouldn't that mean there
>> is
>
> no
>>
>> jank, especially if the resize is async?
>
>
> when WebContentsImpl::CreateRenderViewForRenderManager creates the
> RenderViewHost, it also automatically sets its size to that of
> WebContentsView,
> which is the shorter size at that time.  there's no way to hook into this,
> so i
> found the earliest callback possible, which is RenderViewCreated.  based on
> review feedback on previous cl (from jam@) about adding new interface to
> WebContents, i don't think that would be acceptable here either.
>
> https://chromiumcodereview.appspot.com/21843003/

[kuan, 2013-08-05 19:56:39]

On 2013/08/05 17:45:40, sky wrote:
> Can you resize the WebContentsView first then? Wouldn't that mean
> newly created ones get the right size?
> 
>   -Scott
> 
> On Mon, Aug 5, 2013 at 10:03 AM,  <mailto:[email protected]> wrote:
> > On 2013/08/05 16:54:20, sky wrote:
> >>
> >> > update the size of the WebContents view and the render view
> >> > host for the new page contents to the new taller size
> >> > immediately after the render view has been created, so that
> >> > there's no relayout and resizing.
> >
> >
> >> Can you create the WebContents at the right size? Wouldn't that mean there
> >> is
> >
> > no
> >>
> >> jank, especially if the resize is async?
> >
> >
> > when WebContentsImpl::CreateRenderViewForRenderManager creates the
> > RenderViewHost, it also automatically sets its size to that of
> > WebContentsView,
> > which is the shorter size at that time.  there's no way to hook into this,
> > so i
> > found the earliest callback possible, which is RenderViewCreated.  based on
> > review feedback on previous cl (from jam@) about adding new interface to
> > WebContents, i don't think that would be acceptable here either.
> >
> > https://chromiumcodereview.appspot.com/21843003/

b4 my cl, WebContentsView always follows the size of the active WebView, set in
ContentsContainer::Layout.  on NTP w/ unpinned bmb, this size is the shorter one
(i.e. full tab contents area - height of unpinned bmb).
b4 my cl, the first time the ContentsContainer::Layout sets the size of the
WebView to the full tab contents area height is in
Browser::DidNavigateMainFramePostCommit (via
WebContentsDelegate::DidNavigateMainFramePostCommit), which is too late.
resizng in Browser::DidNavigateToPendingEntry (via
WebContentsDelegate::DidNavigateToPendingEntry), or
WebContentsObserver::AboutToNavigateRenderView, are also too late.

b4 i stumbled on WebContentsObserver::RenderViewCreated, i tried always forcing
WebContentsView to take up the full tab contents area height, regardless of
unpinned bmb - see my initial comments for attempts 2 and 3 at the beginning of
this thread.
attempt 2 fails for 1st tab, because when BrowserWindow::Show is called,
NativeViewHost (child of WebView) always resizes WebContentsView to its size; on
NTP w/ unpinned bmb, WebView is set to the shorter height.
attempt 3 works, except because WebView is taller than the actual visual height
u see, u can't scroll to the bottom of the page.

[sky, 2013-08-05 23:49:11]

With your patch, do we create the renderer at one size only to resize
it shortly after that?

  -Scott

On Mon, Aug 5, 2013 at 12:56 PM,  <[email protected]> wrote:
> On 2013/08/05 17:45:40, sky wrote:
>>
>> Can you resize the WebContentsView first then? Wouldn't that mean
>> newly created ones get the right size?
>
>
>>    -Scott
>
>
>> On Mon, Aug 5, 2013 at 10:03 AM,  <mailto:[email protected]> wrote:
>> > On 2013/08/05 16:54:20, sky wrote:
>> >>
>> >> > update the size of the WebContents view and the render view
>> >> > host for the new page contents to the new taller size
>> >> > immediately after the render view has been created, so that
>> >> > there's no relayout and resizing.
>> >
>> >
>> >> Can you create the WebContents at the right size? Wouldn't that mean
>> >> there
>> >> is
>> >
>> > no
>> >>
>> >> jank, especially if the resize is async?
>> >
>> >
>> > when WebContentsImpl::CreateRenderViewForRenderManager creates the
>> > RenderViewHost, it also automatically sets its size to that of
>> > WebContentsView,
>> > which is the shorter size at that time.  there's no way to hook into
>> > this,
>> > so i
>> > found the earliest callback possible, which is RenderViewCreated.  based
>> > on
>> > review feedback on previous cl (from jam@) about adding new interface to
>> > WebContents, i don't think that would be acceptable here either.
>> >
>> > https://chromiumcodereview.appspot.com/21843003/
>
>
> b4 my cl, WebContentsView always follows the size of the active WebView, set
> in
> ContentsContainer::Layout.  on NTP w/ unpinned bmb, this size is the shorter
> one
> (i.e. full tab contents area - height of unpinned bmb).
> b4 my cl, the first time the ContentsContainer::Layout sets the size of the
> WebView to the full tab contents area height is in
> Browser::DidNavigateMainFramePostCommit (via
> WebContentsDelegate::DidNavigateMainFramePostCommit), which is too late.
> resizng in Browser::DidNavigateToPendingEntry (via
> WebContentsDelegate::DidNavigateToPendingEntry), or
> WebContentsObserver::AboutToNavigateRenderView, are also too late.
>
> b4 i stumbled on WebContentsObserver::RenderViewCreated, i tried always
> forcing
> WebContentsView to take up the full tab contents area height, regardless of
> unpinned bmb - see my initial comments for attempts 2 and 3 at the beginning
> of
> this thread.
> attempt 2 fails for 1st tab, because when BrowserWindow::Show is called,
> NativeViewHost (child of WebView) always resizes WebContentsView to its
> size; on
> NTP w/ unpinned bmb, WebView is set to the shorter height.
> attempt 3 works, except because WebView is taller than the actual visual
> height
> u see, u can't scroll to the bottom of the page.
>
> https://chromiumcodereview.appspot.com/21843003/

[kuan, 2013-08-06 00:12:51]

On 2013/08/05 23:49:11, sky wrote:
> With your patch, do we create the renderer at one size only to resize
> it shortly after that?
> 
>   -Scott

yes it does, unfortunately.

the rvh is created via this codepath:
1) RenderViewHostManager::Navigate
2) UpdateRendererStateForNavigate
3) CreateRenderView
4) InitRenderView
5) WebContentsImpl::CreateRenderViewForRenderManager, which sets the size of rvh
to same as WebContentsView's, which is the shorter size.
6) RenderViewHostImpl::CreateRenderView fires the
WebContentsObserver::RenderViewCreated notification, where i change the size to
the taller one.

so the rvh gets resized b4 it exits RenderViewHostManager::Navigate.

i can't find a way to hook into step 5 to initialize the size, without adding an
api to the public interface of WebContents, which i understand is frowned upon.

without my patch, steps 1 to 5 still happen, but resizing to the taller size
happens in Browser::DidNavigateMainFramePostCommit (via WebContentsDelegate's
method).

btw, my very 1st attempt was to set the background of ContentsContainer to
white, which fixed the gray bar problem completely.  however, i didn't think
that would be acceptable, so i digged further.

[sky, 2013-08-06 14:12:09]

Because the size still effectively changes, how do you know there
won't be a flash?

  -Scott

On Mon, Aug 5, 2013 at 5:12 PM,  <[email protected]> wrote:
> On 2013/08/05 23:49:11, sky wrote:
>>
>> With your patch, do we create the renderer at one size only to resize
>> it shortly after that?
>
>
>>    -Scott
>
>
> yes it does, unfortunately.
>
> the rvh is created via this codepath:
> 1) RenderViewHostManager::Navigate
> 2) UpdateRendererStateForNavigate
> 3) CreateRenderView
> 4) InitRenderView
> 5) WebContentsImpl::CreateRenderViewForRenderManager, which sets the size of
> rvh
> to same as WebContentsView's, which is the shorter size.
> 6) RenderViewHostImpl::CreateRenderView fires the
> WebContentsObserver::RenderViewCreated notification, where i change the size
> to
> the taller one.
>
> so the rvh gets resized b4 it exits RenderViewHostManager::Navigate.
>
> i can't find a way to hook into step 5 to initialize the size, without
> adding an
> api to the public interface of WebContents, which i understand is frowned
> upon.
>
> without my patch, steps 1 to 5 still happen, but resizing to the taller size
> happens in Browser::DidNavigateMainFramePostCommit (via
> WebContentsDelegate's
> method).
>
> btw, my very 1st attempt was to set the background of ContentsContainer to
> white, which fixed the gray bar problem completely.  however, i didn't think
> that would be acceptable, so i digged further.
>
> https://chromiumcodereview.appspot.com/21843003/

[sky, 2013-08-06 15:00:45]

I suspect this would be cleaner, more straightforward and cross platform if
WebContentsDelegate could specify the size for newly created RVHs. Perhaps a
method on WebContentsDelegate for such a thing.

+jam for his thoughts.

On 2013/08/06 14:12:09, sky wrote:
> Because the size still effectively changes, how do you know there
> won't be a flash?
> 
>   -Scott
> 
> On Mon, Aug 5, 2013 at 5:12 PM,  <mailto:[email protected]> wrote:
> > On 2013/08/05 23:49:11, sky wrote:
> >>
> >> With your patch, do we create the renderer at one size only to resize
> >> it shortly after that?
> >
> >
> >>    -Scott
> >
> >
> > yes it does, unfortunately.
> >
> > the rvh is created via this codepath:
> > 1) RenderViewHostManager::Navigate
> > 2) UpdateRendererStateForNavigate
> > 3) CreateRenderView
> > 4) InitRenderView
> > 5) WebContentsImpl::CreateRenderViewForRenderManager, which sets the size of
> > rvh
> > to same as WebContentsView's, which is the shorter size.
> > 6) RenderViewHostImpl::CreateRenderView fires the
> > WebContentsObserver::RenderViewCreated notification, where i change the size
> > to
> > the taller one.
> >
> > so the rvh gets resized b4 it exits RenderViewHostManager::Navigate.
> >
> > i can't find a way to hook into step 5 to initialize the size, without
> > adding an
> > api to the public interface of WebContents, which i understand is frowned
> > upon.
> >
> > without my patch, steps 1 to 5 still happen, but resizing to the taller size
> > happens in Browser::DidNavigateMainFramePostCommit (via
> > WebContentsDelegate's
> > method).
> >
> > btw, my very 1st attempt was to set the background of ContentsContainer to
> > white, which fixed the gray bar problem completely.  however, i didn't think
> > that would be acceptable, so i digged further.
> >
> > https://chromiumcodereview.appspot.com/21843003/

[kuan, 2013-08-07 19:46:33]

hi john,

i've re-implemented this as per scott's suggestion.  this is views only, but
before i continue on to other platforms, i would like to first get your
thoughts/approval on the approach from the WebContentsDelegate perspective i.e.
files in content dir.  ptal.  thanks very much.

btw, i've already discussed offline w/ scott aboutt the Browser and
BrowserWindow changes, so i'll have him review the c/b/ui files when he returns
from OOO.

[jam, 2013-08-07 19:51:26]

On 2013/08/07 19:46:33, kuan wrote:
> hi john,
> 
> i've re-implemented this as per scott's suggestion.  this is views only, but
> before i continue on to other platforms, i would like to first get your
> thoughts/approval on the approach from the WebContentsDelegate perspective
i.e.
> files in content dir.  ptal.  thanks very much.
> 
> btw, i've already discussed offline w/ scott aboutt the Browser and
> BrowserWindow changes, so i'll have him review the c/b/ui files when he
returns
> from OOO.

sorry for the delay, just saw this. in the future please feel free to ping me
over IM if I don't respond in a few hours.

so looking at patchset 3 vs 4, i don't see 4 being much simpler? I prefer not
adding stuff to public APIs if there are existing ways of doing that.

[kuan, 2013-08-07 20:00:57]

On 2013/08/07 19:51:26, jam wrote:
> On 2013/08/07 19:46:33, kuan wrote:
> > hi john,
> > 
> > i've re-implemented this as per scott's suggestion.  this is views only, but
> > before i continue on to other platforms, i would like to first get your
> > thoughts/approval on the approach from the WebContentsDelegate perspective
> i.e.
> > files in content dir.  ptal.  thanks very much.
> > 
> > btw, i've already discussed offline w/ scott aboutt the Browser and
> > BrowserWindow changes, so i'll have him review the c/b/ui files when he
> returns
> > from OOO.
> 
> sorry for the delay, just saw this. in the future please feel free to ping me
> over IM if I don't respond in a few hours.
> 
> so looking at patchset 3 vs 4, i don't see 4 being much simpler? I prefer not
> adding stuff to public APIs if there are existing ways of doing that.

i know we're resistent to adding new public APIs, that's why i've exhausted all
possible ways that don't do that.  unfortunately, all the existing ways (more
than 4 different approaches by now) are not as clean.  as scott has pointed out
(in the thread), they all work around the bug, instead of fixing the real
problem, which is being unable to specify the size of newly-created render views
and hence resulting in them being resized.

[kuan, 2013-08-08 00:00:34]

On 2013/08/07 20:00:57, kuan wrote:
> On 2013/08/07 19:51:26, jam wrote:
> > On 2013/08/07 19:46:33, kuan wrote:
> > > hi john,
> > > 
> > > i've re-implemented this as per scott's suggestion.  this is views only,
but
> > > before i continue on to other platforms, i would like to first get your
> > > thoughts/approval on the approach from the WebContentsDelegate perspective
> > i.e.
> > > files in content dir.  ptal.  thanks very much.
> > > 
> > > btw, i've already discussed offline w/ scott aboutt the Browser and
> > > BrowserWindow changes, so i'll have him review the c/b/ui files when he
> > returns
> > > from OOO.
> > 
> > sorry for the delay, just saw this. in the future please feel free to ping
me
> > over IM if I don't respond in a few hours.
> > 
> > so looking at patchset 3 vs 4, i don't see 4 being much simpler? I prefer
not
> > adding stuff to public APIs if there are existing ways of doing that.
> 
> i know we're resistent to adding new public APIs, that's why i've exhausted
all
> possible ways that don't do that.  unfortunately, all the existing ways (more
> than 4 different approaches by now) are not as clean.  as scott has pointed
out
> (in the thread), they all work around the bug, instead of fixing the real
> problem, which is being unable to specify the size of newly-created render
views
> and hence resulting in them being resized.

on top of that, patch set 3 (without the changes to WebContentsDelegate and
WebContentsImpl) has the undesirable side effect of the NTP render view being
resized while it's still being shown and before the navigation entry for the new
render view is committed.  logically, this side effect could potentially create
jank/flash for some other cases.

[Peter Kasting, 2013-08-08 19:01:43]

Incidentally, from what I understand of this change, I agree that adding to the
content API is desirable here (though I have no opinion on precisely how the
desired functionality is implemented).  From a conceptual point of view, we
really want to create render views at a desired size as opposed to creating them
at a default size and then immediately resizing them.

Just in case that makes John feel any better :)

[jam, 2013-08-09 03:44:58]

i see, ok, thanks for the explanation. lgtm. 

please add a comment to all new methods

[kuan, 2013-08-19 23:09:11]

hi scott,

jam@ has approved the addition of the new method to WebContentsDelegate.
i've gotten the win, cros and linux impls to work, but the mac is beyond me and
sail@ has agreed to take over.
the patches are completely different from what you last reviewed, so i think
it's easier to review the main diff.
i'll get approval from other various owners after i've gotten yours.

https://codereview.chromium.org/21843003/diff/113001/chrome/browser/ui/cocoa/...
File chrome/browser/ui/cocoa/browser_window_cocoa.mm (right):

https://codereview.chromium.org/21843003/diff/113001/chrome/browser/ui/cocoa/...
chrome/browser/ui/cocoa/browser_window_cocoa.mm:767: // RenderWidgetHostView in
(2) and (3).
i've already discussed w/ sail@ abt this.

[sky, 2013-08-20 14:55:21]

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
File chrome/browser/ui/browser_browsertest.cc (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_browsertest.cc:284: gfx::Size created_size;
Isn't this the size of the renderwidgethost too? If so, name it
'render_widget_host_create_size'. Although I would be tempted to remove
'render_widget_host_view' and 'web_contents_view' from the name and document
what they mean.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_browsertest.cc:2323: // A new RenderVieHost should be
created.
ViewHost

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
File chrome/browser/ui/browser_window.h (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_window.h:369: virtual int
GetExtraRenderViewHeightWithoutDetachedBookmarkBar() = 0;
Can we call this GetDetachedBookmarkBarHeight()?

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_view.cc:2618:
DCHECK(browser_->bookmark_bar_state() == BookmarkBar::DETACHED &&
Two questions here. Why do we need to DCHECK the state? Shouldn't it be valid to
invoke this method at any time? Also, could the height be a constant in
c/b/ui/bookmark_bar?

https://codereview.chromium.org/21843003/diff/129001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/21843003/diff/129001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.cc:3556: gfx::Size size =
GetRenderWidgetHostView()->GetViewBounds().size();
What happens if the WebContents changes size between the time the renderview is
created and we end up here?

https://codereview.chromium.org/21843003/diff/129001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.cc:3651: if (rwh_view) {
Is it possible to write tests in content to verify the delegate size is honored?

https://codereview.chromium.org/21843003/diff/129001/content/public/browser/w...
File content/public/browser/web_contents_delegate.h (right):

https://codereview.chromium.org/21843003/diff/129001/content/public/browser/w...
content/public/browser/web_contents_delegate.h:437: // |web_contents|; if
there's no size or no change in size, returns an empty
no change in size?

[kuan, 2013-08-21 15:17:10]

i've addressed all comments in patch set 13.  ptal.  thx.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
File chrome/browser/ui/browser_browsertest.cc (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_browsertest.cc:284: gfx::Size created_size;
On 2013/08/20 14:55:22, sky wrote:
> Isn't this the size of the renderwidgethost too? If so, name it
> 'render_widget_host_create_size'. Although I would be tempted to remove
> 'render_widget_host_view' and 'web_contents_view' from the name and document
> what they mean.

Done.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_browsertest.cc:2323: // A new RenderVieHost should be
created.
On 2013/08/20 14:55:22, sky wrote:
> ViewHost

Done.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
File chrome/browser/ui/browser_window.h (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_window.h:369: virtual int
GetExtraRenderViewHeightWithoutDetachedBookmarkBar() = 0;
On 2013/08/20 14:55:22, sky wrote:
> Can we call this GetDetachedBookmarkBarHeight()?

i'd love to, but unfortunately, it's not exactly that and i worry it might be
mis-leading.  for views, there's the client edge thickness because of overlap w/
toolbar and full-screen etc.  on linux, it's not always the
chrome::kNTPBookmarkBarHeight const.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_view.cc:2618:
DCHECK(browser_->bookmark_bar_state() == BookmarkBar::DETACHED &&
On 2013/08/20 14:55:22, sky wrote:
> Two questions here. Why do we need to DCHECK the state? Shouldn't it be valid
to
> invoke this method at any time? Also, could the height be a constant in
> c/b/ui/bookmark_bar?

Browser::GetSizeForNewRenderView deals with all other cases and only calls
BrowserWindow::GetExtraRenderViewHeightWithoutDetachedBookmarkBar if bookmark
bar is detached and we're navigating away from NTP.  i felt that the different
impls shouldn't have to deal (repeatedly) with cases like if bookmark bar is
even enabled, etc.

unfortunately, i found out the hard way that the height is not as clear-cut as a
constant.  i determine this value by checking the heights of RWHV and WCV before
and after PostCommit; the difference is what this function should return.
on views, there's this trick w/ the client edge thickness because bookmark bar
overlaps w/ toolbar, and when in full-screen etc.
on gtk, the height is not always chrome::kNTPBookmarkBarHeight and is different
when running from chrome and from browser_tests.

https://codereview.chromium.org/21843003/diff/129001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/21843003/diff/129001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.cc:3556: gfx::Size size =
GetRenderWidgetHostView()->GetViewBounds().size();
On 2013/08/20 14:55:22, sky wrote:
> What happens if the WebContents changes size between the time the renderview
is
> created and we end up here?

Done.  i track WCV's size when RWVH was created; if WCV is resized between then
and now, i use the new size of WCV.  this means the RWVH will be resized, but i
guess, or rather hope, it's not common for a user to resize the browser window
between start of navigation entry to its commit.

https://codereview.chromium.org/21843003/diff/129001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.cc:3651: if (rwh_view) {
On 2013/08/20 14:55:22, sky wrote:
> Is it possible to write tests in content to verify the delegate size is
honored?

Done.  fyi, i tried to write the test as a unittest, but had to resort to
browsertest, because the latter doesn't exercise the codepath of
WebContentsDelegate::CreateRenderViewForRenderManager, which is where
WebContentsDelegate::GetSizeForNewRenderView is called.

https://codereview.chromium.org/21843003/diff/129001/content/public/browser/w...
File content/public/browser/web_contents_delegate.h (right):

https://codereview.chromium.org/21843003/diff/129001/content/public/browser/w...
content/public/browser/web_contents_delegate.h:437: // |web_contents|; if
there's no size or no change in size, returns an empty
On 2013/08/20 14:55:22, sky wrote:
> no change in size?

Done.  removed.

[sky, 2013-08-21 20:45:34]

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
File chrome/browser/ui/browser_window.h (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_window.h:369: virtual int
GetExtraRenderViewHeightWithoutDetachedBookmarkBar() = 0;
On 2013/08/21 15:17:11, kuan wrote:
> On 2013/08/20 14:55:22, sky wrote:
> > Can we call this GetDetachedBookmarkBarHeight()?
> 
> i'd love to, but unfortunately, it's not exactly that and i worry it might be
> mis-leading.  for views, there's the client edge thickness because of overlap
w/
> toolbar and full-screen etc.  on linux, it's not always the
> chrome::kNTPBookmarkBarHeight const.

The reason I don't like what you have is that 'extra' here is not clear. Maybe
GetRenderViewHeightInsetWithDetachedBookmarkBar?

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_view.cc:2618:
DCHECK(browser_->bookmark_bar_state() == BookmarkBar::DETACHED &&
On 2013/08/21 15:17:11, kuan wrote:
> On 2013/08/20 14:55:22, sky wrote:
> > Two questions here. Why do we need to DCHECK the state? Shouldn't it be
valid
> to
> > invoke this method at any time? Also, could the height be a constant in
> > c/b/ui/bookmark_bar?
> 
> Browser::GetSizeForNewRenderView deals with all other cases and only calls
> BrowserWindow::GetExtraRenderViewHeightWithoutDetachedBookmarkBar if bookmark
> bar is detached and we're navigating away from NTP.  i felt that the different
> impls shouldn't have to deal (repeatedly) with cases like if bookmark bar is
> even enabled, etc.
> 
> unfortunately, i found out the hard way that the height is not as clear-cut as
a
> constant.  i determine this value by checking the heights of RWHV and WCV
before
> and after PostCommit; the difference is what this function should return.
> on views, there's this trick w/ the client edge thickness because bookmark bar
> overlaps w/ toolbar, and when in full-screen etc.
> on gtk, the height is not always chrome::kNTPBookmarkBarHeight and is
different
> when running from chrome and from browser_tests.

Fair enough, but can't it be valid to invoke at any time?

[kuan, 2013-08-21 22:54:52]

i've addressed all comments in patch set 14.  ptal.  thx.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
File chrome/browser/ui/browser_window.h (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/browse...
chrome/browser/ui/browser_window.h:369: virtual int
GetExtraRenderViewHeightWithoutDetachedBookmarkBar() = 0;
On 2013/08/21 20:45:34, sky wrote:
> On 2013/08/21 15:17:11, kuan wrote:
> > On 2013/08/20 14:55:22, sky wrote:
> > > Can we call this GetDetachedBookmarkBarHeight()?
> > 
> > i'd love to, but unfortunately, it's not exactly that and i worry it might
be
> > mis-leading.  for views, there's the client edge thickness because of
overlap
> w/
> > toolbar and full-screen etc.  on linux, it's not always the
> > chrome::kNTPBookmarkBarHeight const.
> 
> The reason I don't like what you have is that 'extra' here is not clear. Maybe
> GetRenderViewHeightInsetWithDetachedBookmarkBar?

Done.  thx for the name suggestion; i ran out of ideas after 3 attempts.

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/21843003/diff/129001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_view.cc:2618:
DCHECK(browser_->bookmark_bar_state() == BookmarkBar::DETACHED &&
On 2013/08/21 20:45:34, sky wrote:
> On 2013/08/21 15:17:11, kuan wrote:
> > On 2013/08/20 14:55:22, sky wrote:
> > > Two questions here. Why do we need to DCHECK the state? Shouldn't it be
> valid
> > to
> > > invoke this method at any time? Also, could the height be a constant in
> > > c/b/ui/bookmark_bar?
> > 
> > Browser::GetSizeForNewRenderView deals with all other cases and only calls
> > BrowserWindow::GetExtraRenderViewHeightWithoutDetachedBookmarkBar if
bookmark
> > bar is detached and we're navigating away from NTP.  i felt that the
different
> > impls shouldn't have to deal (repeatedly) with cases like if bookmark bar is
> > even enabled, etc.
> > 
> > unfortunately, i found out the hard way that the height is not as clear-cut
as
> a
> > constant.  i determine this value by checking the heights of RWHV and WCV
> before
> > and after PostCommit; the difference is what this function should return.
> > on views, there's this trick w/ the client edge thickness because bookmark
bar
> > overlaps w/ toolbar, and when in full-screen etc.
> > on gtk, the height is not always chrome::kNTPBookmarkBarHeight and is
> different
> > when running from chrome and from browser_tests.
> 
> Fair enough, but can't it be valid to invoke at any time?

Done.  i changed the DCHECK to "if" and return 0.

[sky, 2013-08-21 23:31:38]

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.h (right):

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.h:962: gfx::Size
wcv_size_when_creating_rwhv_;
I'm not sure there is enough. I believe it's possible for multiple RWHVs to be
created before one is displayed. I would ask creis for sure.

[kuan, 2013-08-21 23:35:56]

hi charlie,

could u pls help review the changes in web_contents_impl.h/cc, especially with
respect to scott's question?  thx!

[Charlie Reis, 2013-08-21 23:57:30]

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.h (right):

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.h:962: gfx::Size
wcv_size_when_creating_rwhv_;
On 2013/08/21 23:31:38, sky wrote:
> I'm not sure there is enough. I believe it's possible for multiple RWHVs to be
> created before one is displayed. I would ask creis for sure.

This doesn't seem safe.  There's a RenderWidgetHostView for each RenderViewHost,
and the WebContents can have many RenderViewHosts.  We shouldn't be storing
something about a particular one on WebContents.  (For example, we could cancel
a pending RenderViewHost in favor of a navigation in the current RenderViewHost,
and then this value would be wrong.)

[kuan, 2013-08-22 00:08:03]

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.h (right):

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.h:962: gfx::Size
wcv_size_when_creating_rwhv_;
On 2013/08/21 23:57:30, creis wrote:
> On 2013/08/21 23:31:38, sky wrote:
> > I'm not sure there is enough. I believe it's possible for multiple RWHVs to
be
> > created before one is displayed. I would ask creis for sure.
> 
> This doesn't seem safe.  There's a RenderWidgetHostView for each
RenderViewHost,
> and the WebContents can have many RenderViewHosts.  We shouldn't be storing
> something about a particular one on WebContents.  (For example, we could
cancel
> a pending RenderViewHost in favor of a navigation in the current
RenderViewHost,
> and then this value would be wrong.)

should i store WebContentsView's size in RenderWidgetHostView and provide
getter/setter methods?  also, assuming i store WCV's size correctly, is my logic
in UpdateRendeViewSizeForRenderManager correct?

[Charlie Reis, 2013-08-22 00:25:20]

Ken, perhaps you have a better sense of what should be done instead?

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.h (right):

https://codereview.chromium.org/21843003/diff/155001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.h:962: gfx::Size
wcv_size_when_creating_rwhv_;
On 2013/08/22 00:08:03, kuan wrote:
> On 2013/08/21 23:57:30, creis wrote:
> > On 2013/08/21 23:31:38, sky wrote:
> > > I'm not sure there is enough. I believe it's possible for multiple RWHVs
to
> be
> > > created before one is displayed. I would ask creis for sure.
> > 
> > This doesn't seem safe.  There's a RenderWidgetHostView for each
> RenderViewHost,
> > and the WebContents can have many RenderViewHosts.  We shouldn't be storing
> > something about a particular one on WebContents.  (For example, we could
> cancel
> > a pending RenderViewHost in favor of a navigation in the current
> RenderViewHost,
> > and then this value would be wrong.)
> 
> should i store WebContentsView's size in RenderWidgetHostView and provide
> getter/setter methods?  also, assuming i store WCV's size correctly, is my
logic
> in UpdateRendeViewSizeForRenderManager correct?

I may have to get kenrb's advice here, since I don't really know much about
WebContentsView or RWHV.

My concern is that CreateRenderViewForRenderManager is not always called before
a navigation commits, and it could be called before a navigation that doesn't
commit.  From that perspective, it doesn't seem like a good match, but I don't
fully understand what this value is being used for to be able to recommend
something better.

Examples of problems:
1) CreateRenderViewForRenderManager is called on pending cross-process
navigations that might be canceled, in which case the next commit happens in a
different RenderViewHost.
2) CreateRenderViewForRenderManager is not called when the RenderViewHost has
already been created, which is true for both same-process navigations and
cross-process navigations to a swapped out RenderViewHost (e.g., going back in
some cases).

[kuan, 2013-08-22 13:57:08]

+jochen@, owner of content/browser/web_contents, who may have pointers for
changes in web_contents_impl.h/cc.  thx!

[kenrb, 2013-08-22 18:04:43]

On 2013/08/22 00:25:20, creis wrote:
> > should i store WebContentsView's size in RenderWidgetHostView and provide
> > getter/setter methods?  also, assuming i store WCV's size correctly, is my
> logic
> > in UpdateRendeViewSizeForRenderManager correct?
> 
> I may have to get kenrb's advice here, since I don't really know much about
> WebContentsView or RWHV.
> 

Okay I think I mostly understand the problem, but why can't you call
GetSizeForNewRenderView() again in UpdateRenderViewSizeForRenderManager()? It
doesn't seem like you can rely on the RenderWidgetHostView size (for the reasons
Charlie gives), and a hacky-looking mechanism to detect whether a resize has
occurred doesn't seem an adequate solution.

[kuan, 2013-08-23 16:05:08]

On 2013/08/22 18:04:43, kenrb wrote:
> On 2013/08/22 00:25:20, creis wrote:
> > > should i store WebContentsView's size in RenderWidgetHostView and provide
> > > getter/setter methods?  also, assuming i store WCV's size correctly, is my
> > logic
> > > in UpdateRendeViewSizeForRenderManager correct?
> > 
> > I may have to get kenrb's advice here, since I don't really know much about
> > WebContentsView or RWHV.
> > 
> 
> Okay I think I mostly understand the problem, but why can't you call
> GetSizeForNewRenderView() again in UpdateRenderViewSizeForRenderManager()? It
> doesn't seem like you can rely on the RenderWidgetHostView size (for the
reasons
> Charlie gives), and a hacky-looking mechanism to detect whether a resize has
> occurred doesn't seem an adequate solution.

ah.. i did that in an earlier patch (#4), then changed it when i thought it
broke mac impl.  unfortunately, after i figured out the culprit was something
else, i forgot to revisit the original impl.  shucks.. :(  thx for pointing in
that direction!

in patch set 18, i've changed to call GetSizeForNewRenderView for both
CreateRenderViewForRenderManager and UpdateRenderViewSizeForRenderManager.  i
also modified the tests accordingly, and added resizing in BrowserTest.

scott, it's probably easier to look at delta between patch sets 18 and 14 for
all files except web_contents_impl.h/cc; pls ignore all the intermediate patches
which were unnecessarily complicated and stupid attempts.

[sky, 2013-08-23 16:57:48]

LGTM

[Charlie Reis, 2013-08-23 19:12:34]

content/ LGTM with nits.

https://codereview.chromium.org/21843003/diff/185001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl_browsertest.cc (right):

https://codereview.chromium.org/21843003/diff/185001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl_browsertest.cc:96: //return
!resizing_wcv_ ? rvh_size_ : source->GetView()->GetContainerSize();
nit: Please remove commented out code.

https://codereview.chromium.org/21843003/diff/185001/content/public/browser/w...
File content/public/browser/web_contents_delegate.h (right):

https://codereview.chromium.org/21843003/diff/185001/content/public/browser/w...
content/public/browser/web_contents_delegate.h:438: // |web_contents|; if
there's no size, returns an empty size.
Can you give some sense that this is optional, and will use the current view's
size if the delegate doesn't say otherwise?  (A pending entry doesn't always
create a new render view, so this is a little hard to follow.)

[kuan, 2013-08-26 19:00:46]

charlie, i've addressed ur comments in patch set 18, and make
WebContentsImplBrowserTest resizing work on linux, ptal.

scott, i had to change BrowserTest so that the resizing will also work on linux,
ptal at #18 again.

elliot, ptal at gtk files.

sailesh, ptal at cooca files.

jochen@, if u're back, pls provide owner's approval for changes in
content/browser/web_contents dir.

thx everyone!

https://codereview.chromium.org/21843003/diff/185001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl_browsertest.cc (right):

https://codereview.chromium.org/21843003/diff/185001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl_browsertest.cc:96: //return
!resizing_wcv_ ? rvh_size_ : source->GetView()->GetContainerSize();
On 2013/08/23 19:12:35, creis wrote:
> nit: Please remove commented out code.

Done.

https://codereview.chromium.org/21843003/diff/185001/content/public/browser/w...
File content/public/browser/web_contents_delegate.h (right):

https://codereview.chromium.org/21843003/diff/185001/content/public/browser/w...
content/public/browser/web_contents_delegate.h:438: // |web_contents|; if
there's no size, returns an empty size.
On 2013/08/23 19:12:35, creis wrote:
> Can you give some sense that this is optional, and will use the current view's
> size if the delegate doesn't say otherwise?  (A pending entry doesn't always
> create a new render view, so this is a little hard to follow.)

Done.

[Elliot Glaysher, 2013-08-26 19:17:50]

gtk lgtm

[Charlie Reis, 2013-08-26 19:20:34]

content/ still LGTM.

Also, I'm a content owner, so that's sufficient for
content/browser/web_contents.

https://codereview.chromium.org/21843003/diff/198001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl_browsertest.cc (right):

https://codereview.chromium.org/21843003/diff/198001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl_browsertest.cc:30: // window on
Linux because we don't, the next layout of the unchanged shell
nit: if we don't

https://codereview.chromium.org/21843003/diff/198001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl_browsertest.cc:32: #if
defined(OS_WIN) || defined(OS_CHROMEOS)
nit: Should this just be #if defined(USE_AURA)?

[sky, 2013-08-26 21:05:56]

SLGTM

[sail, 2013-08-26 21:39:41]

cocoa/* LGTM
Will implement the cocoa portion once this lands.

[kuan, 2013-08-26 22:50:46]

charlie, i've addressed the nits in patch set 19.   since u've lgtm'ed (twice in
fact :) thx!), i'm sending this to cq now...

https://codereview.chromium.org/21843003/diff/198001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl_browsertest.cc (right):

https://codereview.chromium.org/21843003/diff/198001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl_browsertest.cc:30: // window on
Linux because we don't, the next layout of the unchanged shell
On 2013/08/26 19:20:35, creis wrote:
> nit: if we don't

Done.

https://codereview.chromium.org/21843003/diff/198001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl_browsertest.cc:32: #if
defined(OS_WIN) || defined(OS_CHROMEOS)
On 2013/08/26 19:20:35, creis wrote:
> nit: Should this just be #if defined(USE_AURA)?

i think SizeContents is better (less steps) than the alternative, so i want that
for non-aura win since it works there.  i changed the flags to a subset of those
in shell.h to reduce confusion, and indicated my pref in the comment.

[commit-bot: I haz the power, 2013-08-26 22:56:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/21843003/219001

[commit-bot: I haz the power, 2013-08-27 11:13:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/21843003/246001

[commit-bot: I haz the power, 2013-08-27 15:29:27]

Change committed as 219794