Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 19 users
Status: Fixed
Owner:
Closed: Jul 12
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 Back to list
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
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
Cc: aval...@chromium.org alex...@chromium.org
Status: Started
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.

Cc: krajshree@chromium.org ligim...@chromium.org lfg@chromium.org pbomm...@chromium.org
 Issue 740254  has been merged into this issue.
Labels: OS-Linux OS-Windows
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.

Labels: M-60 ReleaseBlock-Stable
Project Member Comment 11 by bugdroid1@chromium.org, Jul 12
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

Labels: Merge-Request-60
Status: Fixed
Fixed in 61.0.3155.0. Requesting merge to M60.
Project Member Comment 13 by sheriffbot@chromium.org, Jul 12
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
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
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.
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.

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