lgarron@ could you please take a look!

Alright, I verified this with Sharon's phone in person.

The relevant code [1] exactly matches the Mac code [2]. I don't Some theories:
1. Bug in the iOS beta.
2. Changes in the iOS beta lead to a subtle code path change – seems unlikely, since the icon and color are correct *unless* we're accidentally getting the wrong dark mode value. [3]
2. We're using the API "wrong".

justincohen@, eugenebut@: Any chance you know what might cause our code to lose the strikethrough behaviour?

[1] https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/omnibox/omnibox_view_ios.mm?q=%22addAttribute:NSStrikethroughStyleAttributeName%22&sq=package:chromium&l=671&dr=C
[2] https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/omnibox/omnibox_view_mac.mm?q=%22addAttribute:NSStrikethroughStyleAttributeName%22&sq=package:chromium&l=570&dr=C
[3] https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/omnibox/omnibox_view_ios.mm?type=cs&q=security_state::DANGEROUS&l=637

Adding rohit for Omnibox

Does this repro in Chrome 58.0.3029.6 or later? 

I recently did some significant refactoring of the code in https://codereview.chromium.org/2641003002/ (which landed in 59 and got ported to 58). Now the iOS code matches the Mac code. Prior to that, they were different.

(badssl.com is not reachable at the moment now)
Tested with url: https://tv.eurosport.com
I can still reproduce this on M59.0.3042.0 canary and 58.0.3029.19 beta

This was a bug in iOS8 and looks like it may have regressed again in 10.3 per: https://forums.developer.apple.com/thread/72643

This bug mentions and shows "interstitials", but is the problem limited to the interstitial, or do you see the same bug if you proceed through the interstitial to the actual page?

Both https://forums.developer.apple.com/thread/72643
and http://www.nicnocquee.com/ios/2014/09/22/nsattributedstring-with-nsstrikethroughstyleattributename-bug-in-ios-8.html seem to suggest the same workaround:

"To fix this you just have to assign the strikethrough attribute, NSUnderlineStyleNone to the whole string on initialization."

https://openradar.appspot.com/30739102#ag9zfm9wZW5yYWRhci1ocmRyFAsSB0NvbW1lbnQYgICAyIPT7QoM

its the same problem proceed to the page as well.
https://drive.google.com/file/d/0B-xmXLQhjeKuUlRYdVlMRDlPMTg/view

Thanks for finding those, elawrence@!

rohitrao@, could you handle the fix for this (or find someone)?

I can try it if no one can, but I don't have the appropriate SDK and would prefer to avoid the overhead of installing and switching SDKs.

I let the bots do my last iOS fix, but I have no idea how to test the resulting binaries. 

That said, given this is a non critical bug on a beta OS and the regression has a radar filed against it, does it make sense to try to workaround it if we believe Apple will fix their code before 10.3 ships?

The regression was not fixed by iOS 10.3 Beta 7

This regression was not fixed in the final version of iOS 10.3

I have a Bling checkout, but my simulator only goes up to 10.2; what's the right way for me to upgrade to 10.3?

Xcode 8.3 should have 10.3 Simulator

Bug still exists in iOS 10.3.2 Beta 1.

So the work here is to update OmniboxViewIOS::ApplyTextAttributes with a call like this:

https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/omnibox/omnibox_view_ios.mm?type=cs&q=security_state::DANGEROUS&l=692

+ // Add an attribute to allow strikethough to apply later.  crbug.com/699702 
+ [as addAttribute:NSStrikethroughStyleAttributeName
+            value: [NSNumber numberWithInteger:NSUnderlineStyleNone]
+            range: NSMakeRange(0, [as length]];
+
  // Cache a pointer to the attributed string to allow the superclass'
  // virtual method invocations to add attributes.

The workaround described in Comment #18 isn't effective on iOS 10.3. Instead, adding a dummy attribute (NSBaselineOffsetAttributeName) with its default value (0) seems to work correctly.

https://codereview.chromium.org/2803783002/

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

commit 2352cecca1d2738c6c6b970708286211c29cf16e
Author: elawrence <elawrence@chromium.org>
Date: Thu Apr 06 17:11:41 2017

Ensure strikethrough font renders in omnibox on iOS 10.3

iOS 10.3 introduced a regression in rendering of strings with the
attribute NSStrikethroughStyleAttributeName applied to a subrange of
the string. To workaround this, apply a NSBaselineOffsetAttributeName
attribute with its default value of 0.

BUG= 699702 
TEST=https://expired.badssl.com. Examine https: text in the omnibox,
it should have a line through it.

Review-Url: https://codereview.chromium.org/2803783002
Cr-Commit-Position: refs/heads/master@{#462519}

[modify] https://crrev.com/2352cecca1d2738c6c6b970708286211c29cf16e/ios/chrome/browser/ui/omnibox/omnibox_view_ios.h
[modify] https://crrev.com/2352cecca1d2738c6c6b970708286211c29cf16e/ios/chrome/browser/ui/omnibox/omnibox_view_ios.mm

Verified in emulator. Waiting to verify in Canary.

Verified on iPhone7 on M59.0.3067.0 canary
https text is in strikethrough format.

Based on comment#17 this bug is still in 10.3.2 beta#1, is there any chance that this is fixed in iOS10.3.2 beta#2? Because I can't repro this bug on M57 stable with iOS10.3.2 beta#2.

It looks like the bug is fixed in iOS side10.3.2 beta#2.
On M57 stable 10.3.2 beta#1 Issue is reproduced
but M57 stable 10.3.2 beta#2 Issue is not reproduced.

Re: #23-- Yes, Apple appears to have corrected the regression in iOS 10.3.2 Beta #2, so our workaround should be safe to remove at some point after 10.3.2 releases broadly.

Where should the removal of this workaround be tracked then? In another bug or here?

RE #26: I've filed  Issue 711367 

Thank you!