Issue 723355  has been merged into this issue.

Comment #3 points out a variant whereby URLs using the "blob:" protocol suffer from the same problematic elision.

elawrence@: Are you sure  Issue 723355  is not "working as intended"?
I'm not aware that we try to elide data URLs from the left.

This issue is about logic that does elide URLs, but has a bug.

Re #5: I suppose that's up to you and/or the owner. As currently titled this bug is "Certain URLs don't elide origin correctly" and the duplicated bug is a bug whereby Chrome doesn't elide the URL correctly.

The vague title here is because I can't figure out what conditions trigger this bug.
I'll retitle to be as specific as I know.

Let's keep them separate.

From what I've seen, this issue arises when the omnibox can't display the entire url up to the end of the origin inclusive.

This bug has been public for a long time, so I'm not going to view-restrict it, but really this is a high-sev vulnerability.

tommi, you looked at this in the past if I recall.  It looks like this works on the second load but not the first.  If I kill chrome and click on the link in #1, it is not correctly aligned.  The second click shows the end of the domain as expected.

tommi: Uh oh! This issue still open and hasn't been updated in the last 151 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

tedchoc - I don't recall looking at a similar issue (but it's possible). Can you nudge my memory?  Aside from that, I don't have much time to take a look at this unfortunately and don't even have an android setup atm, so I think it would be good to find another owner.

assigning temparily back to you tedchoc since I'm traveling and don't want to block any progress.

temporarily :)

@tommi, I can understand why you don't recall this because I sent it to the wrong Tomm[i|y]!  That is what I get for trying to do this from my phone.

tommycli@ looked into domain scrolling for RTL issues, and I know he did a fair amount of investigation into what approaches worked and what didn't.  He might have some idea of what is going on here.  Sending your way, but let me know if this seems foreign to you as well :-P

 Issue 755804  has been merged into this issue.

I have a sneaking suspicion that there were two separate levels of regressions (one in March, and one more like August), but I guess we're now using this bug for all of them.

 Issue 760623  has been merged into this issue.

tommycli: Uh oh! This issue still open and hasn't been updated in the last 165 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

tommycli is out until Dec. Given this is marked as high severity, assigning back to tedchoc for triage.

I'll try to see if I can find some incantation of the wonders of Android to make this more robust.  Down the rabbit hole I go.

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

commit 995c535793ecd77fc2661c428d507a017d042db1
Author: Ted Choc <tedchoc@google.com>
Date: Fri Sep 22 19:43:34 2017

[Android] Fix Omnibox URL eliding/positioning.

bringPointIntoView causes issues if you call it back to
back while in a layout pass.  It defers setting the position
till after layout and the last one wins (so our attempt to
ensure the beginning was focused bringPointIntoView(1) would
sometimes be clobbered).

In addition, using setSelection() triggers Android to attempt
to make your selection visible under certain situations (it
attempts on text changes).  When this happens, TextView registers
as a predraw listener and resets the scroll position on the next
draw frame and that can sometimes clobber our attempts of calling
bringPointIntoView.

This disables TextView's handling of bringPointIntoView entirely
when the text isn't focused (and the trailing domain should be
shown).  Instead of relying on that behavior, we now call scrollTo
ourselves with our own calculated positions.

I tested using URLs from the two bugs listed as well as:
 crbug.com/723100 

BUG= 705778 , 705780 

Change-Id: I6b6c7a53ef1a15a32a93773026a48bbc7985771f
Reviewed-on: https://chromium-review.googlesource.com/677881
Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503824}
[modify] https://crrev.com/995c535793ecd77fc2661c428d507a017d042db1/chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java
[modify] https://crrev.com/995c535793ecd77fc2661c428d507a017d042db1/chrome/android/java/src/org/chromium/chrome/browser/toolbar/ToolbarPhone.java

I "believe" this to be fixed.  This fundamentally changed how we were approaching the problem, so I'll appreciate any and all testing on this.

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

FWIW, I don't think we should merge this.  Since this changes fundamentally how we scroll text in the omnibox, I'd rather have this go out in the normal waterfall.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot