What happens with previous version of Chrome (pre-M51)?

We could not see this on the previous versions of Chrome. It seems to affect 51 only. We are testing on 52 and 53 now.

This was actually reported from one of our dogfooders. We could not reproduce then when he rebooted the phone, everything started to work. 
pkl@ : remember the thread with edardiry@ ?

For him it was all links. YouTube, articles,...etc. 

This one is just about ads links? Other links work fine? Could it be something FB is doing?

I tested with facebook.com and cannot repro with a variety of articles and ads. I wonder if it is ad / content / link dependent.

I don't see similar reports in Clank. When I try Safari and Clank, I didn't encounter links not open issue. According to the feedback below, this not only happens to ads links on Facebook. I've seen this issue since M51 release but I wasn't able to reproduce it until today. 

https://hotsauce.corp.google.com/product/282/neutron?lView=td&lRSort=1&lROrder=2&lRFilter=1&lTagId=a11:69647b14:930877&lReportSearch=tag:%23label%3Eblingm51

Claude, are you able to reproduce this with Contextual Search turned off in chrome://flags?

We should try to get this into our M51 respin if possible.

This is starting to show up on some AppStore reviews too. 
Do we have reliable repro case?

Eugene, I am able to reproduce this issue after disabling contextual search from chrome://flags.

What is expected behavior here? Chrome should open a separate Tab or do the navigation in the same Tab?

Also is this reproducible with Safari User Agent? Is this reproducible in Firefox?

Can not reproduce with Chrome 51.0.2704.62 on iOS 9.3.2 iPhone SE. Claude, do you have reliable steps to reproduce or at least device where this bug is reproducible?

Tested on 52.0.2743.35 dev, iPhone5 iOS 9.2.1, iPhone 6 plus iOS 9.3.2 

Sign into facebook
close the tab
open chrome://flags
Disable contextual search
Force quit the chrome app
open facebook.com in the same tab  (type full URL and do not select suggestion)
Try to tap on the ads and articles received from the liked pages and their is no response.

This CL could be a reason of breakage:
https://codereview.chromium.org/1806043004

Claude, could you please ask test team to retest the build before the change and after the change.

Test Update:
- Not able to reproduce the issue on firefox / safari browser.
- Not able to reproduce on chromium build 53.0.2767.0

@eugene - Could you please provide the builds for the change in #20 

51.0.2681.0 should be a good version
51.0.2682.0 is probably a broken version

Thanks!

Testing update: 
Devices: iPhone5S iOS 9.2.1, iPhone 6 plus iOS 9.3.2, iPhone6S iOS 9.2.1

Issue not yet reproducible on 51.0.2681.0 and 51.0.2682.0 builds
We will continue to try to reproduce the issue.

Venkat, could you please try bisecting this bug.

We are working on bisecting the issue.

Test Update:
Does not reproduce on the below builds. Hyd team will continue to try to reproduce.
51.0.2681.0
51.0.2682.0
51.0.2684.0
51.0.2687.0
51.0.2689.0

Could you please try bisecting this:
1.) 51.0.2704.64 is bad revision and 51.0.2689.0 is a good revision
2.) try something in the middle
3.) update good and bad revisions information (f.e. if middle is good then it is a new good revision)
4.) go to the second step

Eugene,

The issue is seen in 51.0.2682.0 
You need to have facebook.com visited few times so that it preloads.

New Steps:
Install Chrome
Goto facebook.com and login with testaccount (blingapp@gmail.com/Bling123)
Visit facebook.com url few times to preload
Open a new tab, and start typing facebook and while the page is preloading tap GO to load the page
Now tap on the links in the posts.
No action performed.

Now goto Settings --> Bandwidth --> Preload webpages --> Never.
Try the same again now links are working.

Video: https://drive.google.com/a/google.com/file/d/0B5Za3nJ_mNRwUi00TnVqRWZLM1k/view?usp=sharing

Please let us know for any more information.

Note: The issue is seen in 51.0.2682.0 and works fine in 51.0.2681.0

Thanks Madhu!

I believe this bug with Preload always existed. Now it's just more visible. Starting from 51.0.2682.0 Chrome blocks dialogs initiated by links with target="_blank" case. In 51.0.2681.0 only JS dialogs, geo dialogs and window.open cases were blocked.

I will take a look if we can fix the actual bug with preload. If the fix is complicated I will rollback 51.0.2681.0 change to mitigate the bug, while we looking for the right fix.

Fix on review: https://codereview.chromium.org/2072553002

Madhu, could you please retest with the next Canary. We would like to include this into respin.

That will be done tonight (US time :) )

Sure Eugene. Latest canary is not available yet. Will be retesting and updating the results once we have one.

MTV and RES are now working on this since the new Canary build is available.

Fix looks good. Links are opening correctly based on the steps from Comment#29.
Verified on Device: iPhone5c, iPhone6s, iPhone6 plus, iPad Air, iPad Pro
iOS: 9.2.1, 9.3.1
Build: 53.0.2770.0 canary

[Automated comment] Request affecting a post-stable build (M51), manual review required.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit c37a95a7b5945958ab7eb31464bc2b6599706a5e
Author: Eugene But <eugenebut@google.com>
Date: Thu Jun 16 21:41:55 2016

[ios] Fixed dialogs suppression.

The issue happened in the following scenario:
 - uer typed in the omnibox to trigger preload
 - preload Tab set shouldSuppressDialogs to YES
 - web view did not exist so suppression was postponed until the load
 - user tapped Go to promote preload Tab to real Tab
 - preload Tab set shouldSuppressDialogs to NO
 - page loaded and postponed suppression suppresses the dialods

This change always cancels postoned suppression if
shouldSuppressDialogs was set to NO.

BUG= 618831 

Review-Url: https://codereview.chromium.org/2072553002
Cr-Commit-Position: refs/heads/master@{#400020}
(cherry picked from commit fc51dd2482615bab3c156bcd5d3744d146be84ee)

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

Cr-Commit-Position: refs/branch-heads/2743@{#372}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/c37a95a7b5945958ab7eb31464bc2b6599706a5e/ios/web/web_state/ui/crw_web_controller.mm

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

commit c49b205d03560a1eba86b348e73a9a402b382ed8
Author: Eugene But <eugenebut@google.com>
Date: Thu Jun 16 21:54:16 2016

[ios] Fixed dialogs suppression.

The issue happened in the following scenario:
 - uer typed in the omnibox to trigger preload
 - preload Tab set shouldSuppressDialogs to YES
 - web view did not exist so suppression was postponed until the load
 - user tapped Go to promote preload Tab to real Tab
 - preload Tab set shouldSuppressDialogs to NO
 - page loaded and postponed suppression suppresses the dialods

This change always cancels postoned suppression if
shouldSuppressDialogs was set to NO.

BUG= 618831 

Review-Url: https://codereview.chromium.org/2072553002
Cr-Commit-Position: refs/heads/master@{#400020}
(cherry picked from commit fc51dd2482615bab3c156bcd5d3744d146be84ee)

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

Cr-Commit-Position: refs/branch-heads/2704@{#724}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/c49b205d03560a1eba86b348e73a9a402b382ed8/ios/web/web_state/ui/crw_web_controller.mm

Verified on iPhone 6S Plus(9.2.1), iPhone 6S(9.3.1) on 49.0.52.0.2743.49 beta. 
Links are opening correctly based on the steps from Comment#29.

Correction: The version is 52.0.2743.49 beta.