New issue
Advanced search Search tips
Starred by 19 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

After HTTP authenticate in inputs (text boxes), the text cursor is not visible

Reported by kuflas...@gmail.com, Jul 6 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. Open new browser window
2. Open site with HTTP authenticate
3. Input credentials after request auth info
4. After loading page put cursor in some input (text box) on page

What is the expected behavior?
Cursor is visible in input (text box) and blinking

What went wrong?
Cursor is not visible in input, but we can input values

Did this work before? N/A 

Chrome version: 59.0.3071.115  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 26.0 r0
 
2017-07-06-1352-6ha2cp6f52.mp4
2.6 MB View Download
Cc: tapted@chromium.org
Components: -UI UI>Browser
[MacTriage] If you create the tab, log in, and get the insertion bug to occur, if you switch to another app and then back to Chrome does the insertion point appear?

When you reproduced the bug in the screencast you showed several text selections and the selection color was gray. When the insertion point flashes correctly what is the selection rect color?

tapted@ - I suspect the httpauth dialog is leaving the browser window as not key?
Cc: a...@chromium.org
Labels: -Pri-2 M-59 Pri-1
Owner: lfg@chromium.org
Status: Assigned (was: Unconfirmed)
I can repro this in Version 61.0.3150.0

Insertion point comes back after any event that defocuses the web contents. (e.g. click other app, click omnibox).

This is a regression in M59.

You are probably looking for a change made after 463464 (known good), but no later than 463479 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/598a769a9e1dc76058c61ccd0c9e2eb60ca776e5..95458fa6c6f719ddf09de4947afdd03069990f16


suspect:

Fix interstitials on OOPIF-based guests.

This CL attaches the interstitial RenderWidgetHostViewChildFrame to a
CrossProcessFrameConnector in a RenderFrameProxyHost in an outer
WebContents when an interstitial page gets attached. It also routes
input events in the interstitial through the delegate's WebContents
RenderWidgetHostInputEventRouter.

BUG= 660373 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2797473005
Cr-Commit-Position: refs/heads/master@{#463473}
Labels: -Type-Bug Type-Bug-Regression

Comment 4 by lfg@chromium.org, Jul 7 2017

Cc: aval...@chromium.org alex...@chromium.org
Status: Started (was: Assigned)
I can reproduce and this issue is Mac-specific. It seems that the frame stays focused, but not active.

Looking at the regression range, my change seems to be the most likely culprit. I think my change only affects pages when showing interstitials, so I guess that the HTTP auth box somehow creates an interstitial?

Adding +avallee@, +alexmos@ who have more expertise on focus in case they have more ideas.

I'm updating/building Mac today to check the issue.

Comment 5 by lfg@chromium.org, Jul 10 2017

Here's why this happens:

In RenderWidgetHostImpl::Focus(), we call the WebContents to get the focused_widget, and set the focus on that widget. Since ShowingInterstitialPage() is true during InterstitialPageImpl::Hide(), the call to Focus there will just re-focus the interstitial, so the original view won't be focused.

Comment 6 by lfg@chromium.org, Jul 11 2017

Cc: krajshree@chromium.org ligim...@chromium.org lfg@chromium.org pbomm...@chromium.org
 Issue 740254  has been merged into this issue.

Comment 7 by lfg@chromium.org, Jul 11 2017

Labels: OS-Linux OS-Windows
Repro steps in 740254 can repro on Windows and Linux as well.

Comment 8 by mmenke@chromium.org, Jul 11 2017

On Windows, when I see auth dialogs, both the user name and password fields have a cursor at once (With only the user name one blinking).  Is this the same issue, or should I file another bug?

Comment 9 by lfg@chromium.org, Jul 11 2017

Re#8: Separate issue, please file a new bug. I can also see the two cursors (one not blinking) on Canary windows, but it's fine on dev channel 61.0.3135.4, so it must be a recent regression.

Comment 10 by lfg@chromium.org, Jul 11 2017

Labels: M-60 ReleaseBlock-Stable
Project Member

Comment 11 by bugdroid1@chromium.org, Jul 12 2017

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

commit 7f1241d2872150eb54fc10268ef03a2d2aca7bce
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Wed Jul 12 01:45:04 2017

Fix focus after an interstitial is destroyed.

When an interstitial is created, it steals the page's focus. When it is
destroyed, it is supposed to return focus to the page, however, since
the WebContents still thinks an interstitial is being displayed, the
RenderWidgetHostImpl tries to maintain the focus on the interstitial.
This CL fixes that by moving the Focus() call into
WebContentsImpl::DetachInterstitialPage, instead of being called in
InterstitialPageImpl::Hide.

Bug:  739676 
Change-Id: I9eff1af3cb1500cc3f38400ae9e13e553bb0cf54
Reviewed-on: https://chromium-review.googlesource.com/565172
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485782}
[modify] https://crrev.com/7f1241d2872150eb54fc10268ef03a2d2aca7bce/content/browser/frame_host/interstitial_page_impl.cc
[modify] https://crrev.com/7f1241d2872150eb54fc10268ef03a2d2aca7bce/content/browser/frame_host/interstitial_page_impl_browsertest.cc
[modify] https://crrev.com/7f1241d2872150eb54fc10268ef03a2d2aca7bce/content/browser/frame_host/navigation_controller_delegate.h
[modify] https://crrev.com/7f1241d2872150eb54fc10268ef03a2d2aca7bce/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/7f1241d2872150eb54fc10268ef03a2d2aca7bce/content/browser/web_contents/web_contents_impl.h

Comment 12 by lfg@chromium.org, Jul 12 2017

Labels: Merge-Request-60
Status: Fixed (was: Started)
Fixed in 61.0.3155.0. Requesting merge to M60.
Project Member

Comment 13 by sheriffbot@chromium.org, Jul 12 2017

Labels: -Merge-Request-60 Hotlist-Merge-Review Merge-Review-60
This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-60 Merge-Approved-60
Approving merge to M60. 
Project Member

Comment 15 by bugdroid1@chromium.org, Jul 13 2017

Labels: -merge-approved-60 merge-merged-3112
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8d1af9055ccd9693de85cd2c84f94a84365e875d

commit 8d1af9055ccd9693de85cd2c84f94a84365e875d
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Thu Jul 13 18:06:27 2017

Fix focus after an interstitial is destroyed. (Merge to M60)

When an interstitial is created, it steals the page's focus. When it is
destroyed, it is supposed to return focus to the page, however, since
the WebContents still thinks an interstitial is being displayed, the
RenderWidgetHostImpl tries to maintain the focus on the interstitial.
This CL fixes that by moving the Focus() call into
WebContentsImpl::DetachInterstitialPage, instead of being called in
InterstitialPageImpl::Hide.

TBR=lfg@chromium.org

(cherry picked from commit 7f1241d2872150eb54fc10268ef03a2d2aca7bce)

Bug:  739676 
Change-Id: I9eff1af3cb1500cc3f38400ae9e13e553bb0cf54
Reviewed-on: https://chromium-review.googlesource.com/565172
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#485782}
Reviewed-on: https://chromium-review.googlesource.com/569843
Cr-Commit-Position: refs/branch-heads/3112@{#605}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/8d1af9055ccd9693de85cd2c84f94a84365e875d/content/browser/frame_host/interstitial_page_impl.cc
[modify] https://crrev.com/8d1af9055ccd9693de85cd2c84f94a84365e875d/content/browser/frame_host/interstitial_page_impl_browsertest.cc
[modify] https://crrev.com/8d1af9055ccd9693de85cd2c84f94a84365e875d/content/browser/frame_host/navigation_controller_delegate.h
[modify] https://crrev.com/8d1af9055ccd9693de85cd2c84f94a84365e875d/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/8d1af9055ccd9693de85cd2c84f94a84365e875d/content/browser/web_contents/web_contents_impl.h

This issue is not fixed and my application failed after last weeks chrome update. I have detailed my issue here. Telerik was also able to confirm the issue at Chrome's end and the links to the demo site is mentioned here.

https://bugs.chromium.org/p/chromium/issues/detail?id=743023
So this was exactly my issue. So when this is marked as fixed, will it be patched in the next release ? For the time being, I am forced to show a javascript alert in my application, which fixes  the issue. 

Because of this focus issue, jquery validate fails at other pages, which does not make sense. But once I have the alert in my main page, everything works.

Sample
http://dev.dimodi.com/chrome-focus/

So should i delete,  issue #743023 . It looks like i created a duplicate ticket
Project Member

Comment 18 by bugdroid1@chromium.org, Jul 14 2017

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

commit 403d97b93b3b13a3eafed9651a70be0862e503fa
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Fri Jul 14 22:30:09 2017

Revert "Fix focus after an interstitial is destroyed. (Merge to M60)"

This reverts commit 8d1af9055ccd9693de85cd2c84f94a84365e875d.

Reason for revert: appears to break lots of tests on beta builder.

Original change's description:
> Fix focus after an interstitial is destroyed. (Merge to M60)
> 
> When an interstitial is created, it steals the page's focus. When it is
> destroyed, it is supposed to return focus to the page, however, since
> the WebContents still thinks an interstitial is being displayed, the
> RenderWidgetHostImpl tries to maintain the focus on the interstitial.
> This CL fixes that by moving the Focus() call into
> WebContentsImpl::DetachInterstitialPage, instead of being called in
> InterstitialPageImpl::Hide.
> 
> TBR=lfg@chromium.org
> 
> (cherry picked from commit 7f1241d2872150eb54fc10268ef03a2d2aca7bce)
> 
> Bug:  739676 
> Change-Id: I9eff1af3cb1500cc3f38400ae9e13e553bb0cf54
> Reviewed-on: https://chromium-review.googlesource.com/565172
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Commit-Queue: Lucas Gadani <lfg@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#485782}
> Reviewed-on: https://chromium-review.googlesource.com/569843
> Cr-Commit-Position: refs/branch-heads/3112@{#605}
> Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

TBR=creis@chromium.org,alexmos@chromium.org,lfg@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  739676 
Change-Id: I52f1f9b44ab4ce1b6ea9b19b7708df1f7bb787aa
Reviewed-on: https://chromium-review.googlesource.com/572460
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#610}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/403d97b93b3b13a3eafed9651a70be0862e503fa/content/browser/frame_host/interstitial_page_impl.cc
[modify] https://crrev.com/403d97b93b3b13a3eafed9651a70be0862e503fa/content/browser/frame_host/interstitial_page_impl_browsertest.cc
[modify] https://crrev.com/403d97b93b3b13a3eafed9651a70be0862e503fa/content/browser/frame_host/navigation_controller_delegate.h
[modify] https://crrev.com/403d97b93b3b13a3eafed9651a70be0862e503fa/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/403d97b93b3b13a3eafed9651a70be0862e503fa/content/browser/web_contents/web_contents_impl.h

Comment 19 by lfg@chromium.org, Jul 17 2017

 Issue 743023  has been merged into this issue.

Comment 20 by lfg@chromium.org, Jul 17 2017

Labels: -merge-merged-3112
+govind FYI

This patch caused issues when merged to the M60 branch (Thanks Alex for reverting it!). I haven't confirme, but likely there are dependencies on other patches landed after M60 branched. Given that:

1. We are less than a week from release.
2. There is an existing workaround explained in  issue 740254 .

I won't be merging this fix back to M60. Fix will be on M61 through the normal release process.

Comment 21 by lfg@chromium.org, Jul 17 2017

Cc: gov...@chromium.org
+govind FYI
Cc: bustamante@chromium.org
+bustamante@ (M60 Desktop Release owner) FYI
Cc: manoranj...@chromium.org
 Issue 740652  has been merged into this issue.
// This javascript (jquery) WORKAROUND tests for  bug 739676  active,
// If has triggered, displays meaningless alert,
// Alert blur/close heals window/element focus/blur problems.
// Bug (rarely) triggers; only on bookmark (or typed URL) to auth protected page,
// only when session not previously authenticated.
// Your more elegant workaround (that never bothers user) welcome/appreciated.
$(function(){
  // create temporary, invisible input element
  var temporaryInput=$('<input style="opacity:0; background-opacity:0; position:fixed;">');
  // style="height:1px; width:1px;" 
  function whenDone(){ 
    temporaryInput.remove();
    // Here, do anything else you might want do to for normal startup
    $('input').first().focus(); 
  }
  var delayedFix=setTimeout(function(){
    // temporaryInput.focus() failed, so bug has triggered,
    whenDone();
    // misc alert, when done, will restore proper window/field focus 
    alert('This temporary alert counteracts auth-input-focus'
      +'  bug #739676  in Chrome versions 59 and 60.'
      );  
  },250 /* milliseconds delayed*/)
  $('body').prepend(temporaryInput);
  temporaryInput.on('focus',function(){
    // If temporaryInput.focus() succeeds before timeout then bug is not active,
    // fix not required
    clearTimeout(delayedFix);
    whenDone();
  })
  temporaryInput.focus();
})

Comment 25 by thrtw...@gmail.com, Jul 20 2017

Here is the fix I have been using, which is similar to https://bugs.chromium.org/p/chromium/issues/detail?id=740652#c11.

The first click on an input will open and close a new window/tab unless focus() is working. The handlers are removed either way.

$(function () {
    var inputs = 'input:visible';
    var events = ['click.focusfix', 'focus.focusfix'];
    function disableFocusfix() {
        $('body').off(events.join(' '), inputs);
    }
    $('body')
        .on(events[0], inputs, function () {
            if (location.hash != '#focus') {
                window.open(location.href + '#focus', '_blank').close();
                disableFocusfix();
            }
        })
        .on(events[1], inputs, disableFocusfix)
        .find(inputs).first().focus().blur();
});

 Issue 739493  has been merged into this issue.
 Issue 753114  has been merged into this issue.
Cc: pnangunoori@chromium.org
 Issue 758187  has been merged into this issue.

Comment 29 Deleted

When we will expect this bug to be fixed in Production ?

Comment 31 by lfg@chromium.org, Sep 6 2017

Re#30: Chrome 61 launched yesterday (see https://chromereleases.googleblog.com/2017/09/stable-channel-update-for-desktop.html). It should be fixed as soon as you get the update.
tested, fixed.
Can confirm, works good on Chrome 61. Thank you.

Sign in to add a comment