New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users
Status: Fixed
Owner:
ooo Nov 8 - 19
Closed: Jun 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment
Regression : Not able to insert data in Sign in fileld using tap/touch when New profile management flag is on.
Reported by adha...@etouch.net, Jan 20 2015 Back to list
Chrome Version       : 41.0.2272.12 (Official Build) Revision 45789433fd4807a82db53535a134af4bfd5356c7-refs/branch-heads/2272@{#50} (32/64 bit)
OS : Windows 8 (Touch Specific)

What steps will reproduce the problem?
1. Launch chrome, navigate to 'chrome://flags' and enable "New Profile Management" flag, relaunch the browser.
2. Tap/touch on user icon at right top of the browser window & tap on "Sign in to chrome" button.
3. Then Tap/Touch in Email/Password field to enter text using virtual keyboard (Touch),observe.

Using tap/touch highlighted focus not seen in Email/Password field due to which not able to insert any data using virtual keyboard(Touch)

Using tap/touch Email/Password field should get highlighted & data should get inserted in same filed using virtual keyboard(Touch).

This is a touch specific regression issue broken in M-41.

Below is the narrow bisect info :
https://chromium.googlesource.com/chromium/src/+log/4738956a5ef569750b4a7038f7a9971fec8ae7e1..5b66355756c3c277f153c9f091138a3bd6b7609e?pretty=fuller&n=10000 

Suspecting : r310404 ?

@rogerta : Please reassign it if your change has not cause for the same.
 
Exp_focus.jpg
246 KB View Download
Act_result_focus.jpg
144 KB View Download
Labels: ReleaseBlock-Stable
Adding RB label as this is a regression issue, kindly change it if this is not a blocker.
Labels: -ReleaseBlock-Stable
The feature is still behind the flag , hence not a blocker.
Cc: fsam...@chromium.org
I am able to repro this with latest  42.0.2291.0 canary on windows 8.  This feature is no longer behind a flag.  Note that this problem does not occur on the full tab login page, only the login page from the drop down menu as seen in screenshots.

Fady: could it be a missing tab helper?
Cc: rbyers@chromium.org wjmaclean@chromium.org
Owner: wjmaclean@chromium.org
+wjmaclean@ as owner.
+rbyers@: Touch TL
Labels: Cr-Platform-Apps-BrowserTag
Adding BrowserTag label.
Status: Started
I've spent some time debugging this. I don't have a fix yet, though I *think* I know what is going on.

First, note that this seems to work properly on Linux, and I've been doing comparitive testing between Linux and Windows builds.

On Windows, it seems that when the signin overlay opens and you tap on it, the GestureTap events are being received by the page, but *the window itself is not being made active* and thus does not have focus. Note that the text fields change their focus rings in response to being tapped, but wince the window does not have focus I'm guessing it assumes no keyboard input is possible, and as such the text fields don't display a cursor.

If you use a mouse to focus the window (click anywhere inside the overlay), then the text fields start to work. They continue to work even if you move focus out of the window (e.g. tap in the current tab contents) and then return focus to the overlay with a GestureTap. It is just the initial focusing of the window that seems to be affected.

My current debugging efforts involved examining what's happening in the pathways that call RenderWidgetHostViewAura::OnWindowFocused(). On Linux, tapping in the overlay area causes this function to be called, and it provides an indication that the overlay has indeed received focus. On Windows, this function is not called in response to tapping in the overlay, though it is called on re-focus taps after the window has received initial focus by other means.
I forgot to mention ... so far my debugging has not implicated any of the plugin-related mechanisms or BrowserPlugin*, so this may not be WebView related. But best to keep that tag in place for now until we know for sure.
Sounds like the right fix would be to focus the window that pops up after step (2). Is that not happening for some reason on Windows?
We could do that, but then this same sort of bug could occur elsewhere. I had a discussion with rbeyers@ and he felt that, since a mouse-click will focus the window, it's reasonable for the touch start to do so as well.
Oh, to answer your question: when the window pops up, it is not focused on either Linux or Windows.
Labels: OS-Linux
This isn't an area of the code I'm too familiar with but I think the question is, why is this working with clicks but not touch? What's different about touch? I would take a look at the stack track leading to RenderWidgetHostViewAura::OnWindowFocused and look at the code path on click, and make sure we take a similar code path on touch.

base::debug::StackTrace().Print() is super helpful to very quickly determine stack traces.
Re #12

The short answer to your question is that, or a touch event:
1) the embedder gets first crack at the event,
2) BrowserPlugin forwards the event to the guest, *but* tells the embedder renderer that it *consumed* the event, then
3) RWHVA::ProcessAckedTouchEvent passes the event into the usual machinery, but with the 'handled' flag set, and then
4) the TouchDispositionGestureFilter sees the event has been handled, and so drops it from the queue, and finally
5) the touch/gesture never makes it far enough to hit the code that focuses the window. Without focus, the window cannot accept keyboard input.

The TouchDispositionGestureFilter drops the event here
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/gesture_detection/touch_disposition_gesture_filter.cc&rcl=1433748798&l=455
and here
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/gesture_detection/touch_disposition_gesture_filter.cc&rcl=1433748798&l=261

Item (2) explains why this only affects WebView: if we load the same page without WebView then the rest of the chain works properly.

Finally, this seems specific to the *first* time the window is focused (as noted above), so if it is focused by its creator, then touch can re-focus it even if a WebView is in use, hence why the in-tab-version of the signin page doesn't seem to have this problem. 
Sorry, I forgot to mention; none of this applies to clicks since they don't seem to care about the consumed state of the event for applying focus, though this comment is based purely on observation, and not from tracing that code path in great detail.
Project Member Comment 15 by bugdroid1@chromium.org, Jun 22 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6aefc3a6c8aa7463906af62205b0f0c314c3ef76

commit 6aefc3a6c8aa7463906af62205b0f0c314c3ef76
Author: wjmaclean <wjmaclean@chromium.org>
Date: Mon Jun 22 21:58:29 2015

Force a GuestView's embedder to be focused on TouchStart.

It is currently possible that touching (TouchStart) an element inside a
GuestView may not focus the element because the embedder itself has not
received focus. An example of this is when a <webview> tag is contained
inside a views::WebView. The views::WebView is unable to receive touch
events in order to focus itself, and the BrowserPlugin marks the touch
event as handled so that Aura never generates the GestureTap that
RenderWidgetHostViewAura requires to focus the views::WebView.

This CL adds logic in RenderWidgetHostViewGuest to detect an unfocused
embedder, and to focus it on TouchStart.

BUG= 450147 

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

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

[modify] http://crrev.com/6aefc3a6c8aa7463906af62205b0f0c314c3ef76/chrome/browser/apps/guest_view/web_view_browsertest.cc
[modify] http://crrev.com/6aefc3a6c8aa7463906af62205b0f0c314c3ef76/content/browser/frame_host/render_widget_host_view_guest.cc
[modify] http://crrev.com/6aefc3a6c8aa7463906af62205b0f0c314c3ef76/content/public/test/browser_test_utils.cc
[modify] http://crrev.com/6aefc3a6c8aa7463906af62205b0f0c314c3ef76/content/public/test/browser_test_utils.h

Status: Fixed
This should be fixed not ... can someone please verify?
Cc: joberbeck@chromium.org rogerta@chromium.org jsc...@chromium.org anthonyvd@chromium.org shrikant@chromium.org
 Issue 516711  has been merged into this issue.
 Issue 516291  has been merged into this issue.
Sign in to add a comment