[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?

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}

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.

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.

 Issue 740254  has been merged into this issue.

Repro steps in 740254 can repro on Windows and Linux as well.

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?

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.

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

Fixed in 61.0.3155.0. Requesting merge to M60.

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

Approving merge to M60. 

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

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

 Issue 743023  has been merged into this issue.

+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.

+govind FYI

+bustamante@ (M60 Desktop Release owner) FYI

 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();
})

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.

 Issue 758187  has been merged into this issue.

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

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.