Linux: App windows with frame: none now have resize handles.

Linux: App windows with frame: none now have resize handles.

ChromeNativeAppWindowViews now installs the EasyResizeWindowTargeter
into the content window, not its root window. The root window does not
have a delegate, which means it doesn't handle events on Linux.

BUG=357049
COLLABORATOR=sadrul@chromium.org
TEST=Open Text chrome app. All edges and corners should be draggable to
resize the app.

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

[Matt Giuca, 2014-04-08 09:24:32]

sadrul: You understand this the best.
benwells: OWNERS, plus I think you did the original Windows fix for this issue.

Note: It clearly isn't submittable in this state, but hopefully the tests will
help me explain my confusion. (It is a good starting point.)

https://codereview.chromium.org/224903022/diff/1/chrome/browser/ui/views/apps...
File chrome/browser/ui/views/apps/shaped_app_window_targeter_unittest.cc
(right):

https://codereview.chromium.org/224903022/diff/1/chrome/browser/ui/views/apps...
chrome/browser/ui/views/apps/shaped_app_window_targeter_unittest.cc:213: // will
fail).
Please see my comment #17 and #18 on http://crbug.com/357049. I really don't
understand what EWRT is doing given that, after this patch, it seems to be just
taking messages intended for the window, and redirecting them to... the same
window (no longer the root window). So I don't understand how to make this test
test anything because I don't know what effect the EWRT is now having after this
patch.

[sadrul, 2014-04-08 21:20:17]

The change in ChromeNativeAppWindowViews lgtm. You can probably make the test
better if c#19 on the bug makes sense.

[benwells, 2014-04-08 22:18:25]

This is totally going to clash with a change I just put in the CQ. Are you
planning on merging this into M35?

[benwells, 2014-04-08 22:20:18]

On 2014/04/08 22:18:25, benwells wrote:
> This is totally going to clash with a change I just put in the CQ. Are you
> planning on merging this into M35?

Correction, this is going to clash with a change that just landed.

[Matt Giuca, 2014-04-09 06:17:39]

Referring to this one:
https://codereview.chromium.org/213743017 (r262516)

Yeah this is a problem. We *really* need to merge this to M35. Is your change
urgent (i.e., are other things blocking on it)? I think the best way forward
would be to:
1. revert your change
2. commit my change
3. revert the revert (dealing with the merge conflict at that point)
4. merge #2.

I am happy to do all three of these, or you can do #3 if you want to have more
control. Is that acceptable? Sorry to cause you trouble.

[Matt Giuca, 2014-04-09 09:30:06]

As discussed on the bug, I don't think this test ever made any sense. I am not
making it any *worse* so I think it's safe to commit it even though the test
looks kind of silly at this point. I have added a nice big TODO explaining the
problem.

I have prepared a CL to revert Ben's change:
https://codereview.chromium.org/229343004

This CL applies cleanly to master + that revert. After this goes through, I will
re-apply Ben's patch with my change merged in. And then later I will look at
making this test make more sense. In the mean time, I can get this CL merged
into M35, hopefully without any trouble.

PTAL.

[Matt Giuca, 2014-04-09 09:34:57]

Actually, merging my change with yours is a disaster because I took the #ifdef
OS_WIN code and made it !OS_CHROMEOS, and you moved it into
ChromeNativeAppWindowViewsWin. That will have to be refactored differently. I'll
hold off on preparing the revert-of-the-revert until everything else is sorted
out.

[benwells, 2014-04-09 16:36:25]

On 2014/04/09 09:34:57, Matt Giuca wrote:
> Actually, merging my change with yours is a disaster because I took the #ifdef
> OS_WIN code and made it !OS_CHROMEOS, and you moved it into
> ChromeNativeAppWindowViewsWin. That will have to be refactored differently.
I'll
> hold off on preparing the revert-of-the-revert until everything else is sorted
> out.

Yes, indeed. FWIW I'd prefer to keep the code clean and have a messy test than
visa versa. I also like the test better after my change as I think it is testing
the real situation better..

[Matt Giuca, 2014-04-09 23:30:31]

On 2014/04/09 16:36:25, benwells wrote:
> On 2014/04/09 09:34:57, Matt Giuca wrote:
> > Actually, merging my change with yours is a disaster because I took the
#ifdef
> > OS_WIN code and made it !OS_CHROMEOS, and you moved it into
> > ChromeNativeAppWindowViewsWin. That will have to be refactored differently.
> I'll
> > hold off on preparing the revert-of-the-revert until everything else is
sorted
> > out.
> 
> Yes, indeed. FWIW I'd prefer to keep the code clean and have a messy test than
> visa versa.

Yeah I haven't figured out how to fix the test yet, but it would involve work on
the test harness, not changes to the code.

> I also like the test better after my change as I think it is testing
> the real situation better..

OK but what does that mean for this CL? It's going to go in before your CL. I
don't think we're going to get good tests for M35. Can we commit this one as-is
or are there changes you want to see?

[benwells, 2014-04-10 01:22:33]

lgtm

[Matt Giuca, 2014-04-10 05:12:24]

The CQ bit was checked by mgiuca@chromium.org

[commit-bot: I haz the power, 2014-04-10 05:12:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mgiuca@chromium.org/224903022/20001

[commit-bot: I haz the power, 2014-04-10 13:33:44]

Change committed as 262965