New issue
Advanced search Search tips

Issue 591016 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Dec 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

MacViews: Focus not leaving omnibox correctly.

Reported by k...@yandex-team.ru, Mar 1 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 YaBrowser/16.2.0.2567 (beta) Safari/537.36

Steps to reproduce the problem:
1.  Open MacViews browser.
2.  Click on omnimox, type something, ensure that suggest is visible
3.  Click on tab contents.

What is the expected behavior?
Suggest closed.
Cursor moved to page content.

What went wrong?
Suggest still visible.
Omnibox still contains blinking cursor, but page accepts input correctly.

Did this work before? No 

Chrome version: 51.0.2664.0  Channel: dev
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 20.0 r0

I've investigate this a little.
Now MacViews browser window usually contains two native views:
WebContentsView and BridgedContentView.

But widget FocusManager handles only changing of active NSWindow, not changing first responder between WebContentsView and BridgedContentView.
So OmniboxViewViews::OnBlur() is not invoked when move focus to tab contents.
 
Components: -UI Internals>Views
Labels: Hotlist-MacViews
Status: Available (was: Unconfirmed)
Project Member

Comment 3 by bugdroid1@chromium.org, Mar 7 2016

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

commit c2936ff6d9dfed0b4fea95575a1a3a099b46be5d
Author: kirr <kirr@yandex-team.ru>
Date: Mon Mar 07 07:58:19 2016

MacViews: Handling changing of first responder inside NativeWidgetMac.

NativeWidgetMac usually contains more then one NSView.
For example browser window contains ViewsCompositorSuperview and WebContentsView.
So views::FocusManager must handle not only changing of key NSWindow,
but also changing of first responder inside NSWindow, that holds
NativeWidget.

BUG= 591016 

Review URL: https://codereview.chromium.org/1759913004

Cr-Commit-Position: refs/heads/master@{#379525}

[modify] https://crrev.com/c2936ff6d9dfed0b4fea95575a1a3a099b46be5d/ui/views/cocoa/bridged_content_view.mm
[modify] https://crrev.com/c2936ff6d9dfed0b4fea95575a1a3a099b46be5d/ui/views/widget/native_widget_mac_unittest.mm

Project Member

Comment 4 by bugdroid1@chromium.org, Mar 8 2016

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

commit 3436bb5299b3c8becec4c7033c25f3f8c70c5692
Author: tapted <tapted@chromium.org>
Date: Tue Mar 08 07:14:41 2016

Fix Mac views_unittests regressions after r379525

All the BridgedNativeWidgetTest tests, and
NativeWidgetMacTest.NonWidgetParent crash after r379525. The problem is
an inability to obtain the Widget's focus manager when a native focus
change occurs because the test harness doesn't have one at that point.

For BridgedNativeWidgetTest, Widget::Close(..) normally informs the
BridgedNativeWidget that the views::RootView is about to be destroyed,
but this unit test harness doesn't use views::Widgets, so that part
needs to be mocked out.

NativeWidgetMacTest.NonWidgetParent was creating a `child` Widget, which
relies on the FocusManager provided by a parent Widget which wasn't
present.

BUG= 591016 
TBR=kirr@yandex-team.ru

Review URL: https://codereview.chromium.org/1772153002

Cr-Commit-Position: refs/heads/master@{#379773}

[modify] https://crrev.com/3436bb5299b3c8becec4c7033c25f3f8c70c5692/ui/views/cocoa/bridged_native_widget_unittest.mm
[modify] https://crrev.com/3436bb5299b3c8becec4c7033c25f3f8c70c5692/ui/views/widget/native_widget_mac_unittest.mm

Labels: -Hotlist-MacViews Proj-MacViews
Status: Fixed (was: Available)

Sign in to add a comment