Adjusting the title to match the result of the discussion

Hi,

I noticed that eliding code performance is suboptimal when there are >700 origins displayed in the list.

Specifically, this bit https://cs.chromium.org/chromium/src/chrome/browser/resources/options/password_manager.js?rcl=0&l=206 — it reads offset on each iteration and chops the string char by char. 

This makes the list of 1k origins stall for 13-15 seconds. Consider using CSS for text trimming or maybe there is a better way to handle this is JS.

Thanks

yep, left eliding code is feasible

Uploading Screenshots for Code Review.

Deleted: Left_Elide_Origin.png 50.9 KB

	Left_Elide_Origin.png 50.9 KB View Download

Deleted: Long_Username_Breaks_Design.png 54.0 KB

	Long_Username_Breaks_Design.png 54.0 KB View Download

Thanks for taking this, Jan. 

Please make sure that the eliding works for right-to-left languages and ChromeVox reads them correctly.

To check RTL languages, you could run Chrome from the command line like here:
export LANGUAGE=he_IL && out/Release/chrome

FYI, here are previous CLs and discussions https://codereview.chromium.org/1318523011/ https://codereview.chromium.org/1823423002/

Thanks for your remarks, Maxim.

I tested my change against RTL and LTR locales, Screenshots are attached. 

Regarding screenreaders: I failed to get ChromeVox running with md-settings, it does not seem to recognize any displayed text. However, I ported my changes to the old dialog (chrome://settings/password), where ChromeVox worked just fine, even with |direction: rtl|. In particular, I failed to reproduce  http://crbug.com/595276 , it looks like this is supported in newer Chrome versions.

A last issue remains with URLs that contain non-ASCII characters from a RTL language, for example http://اسماء.شبكة
 (http://xn--ggbla1c4e.xn--ngbc5azd/). When adding passwords from this domain Password Manager saves the human unreadable |xn--$PUNYCODE| version (background: https://en.wikipedia.org/wiki/Internationalized_domain_name#Top-level_domain_implementation). If the display of these URLs changes in the future, we would need to set |direction: ltr| in order to avoid hiding of the TLD. Example screenshots are attached. Note that I forced the display of the human readable URL through using Chrome Dev Tools, there is currently no way to achieve this using just saving passwords.

Deleted: Arabic_LTR.png 9.9 KB

	Arabic_LTR.png 9.9 KB View Download

Deleted: Arabic_RTL.png 10.2 KB

	Arabic_RTL.png 10.2 KB View Download

Deleted: LTR_Locale.png 40.9 KB

	LTR_Locale.png 40.9 KB View Download

Deleted: RTL_Locale.png 32.2 KB

	RTL_Locale.png 32.2 KB View Download

dtseng@: any reason to believe that cvox handles text direction differently these days?

I assume you're using ChromeVox from the webstore? ChromeVox the extension), does not support polymer (shadow dom) so won't read anything in md-settings. If you're on a Mac, use VoiceOver (cmd+f5); on Windows, use NVDA (www.nvda-project.org); on Chrome OS use ChromeVox (ctrl+alt+z).

Yes, I was using ChromeVox from the webstore. Thanks for your comments, what should I be using on my dev machine running Goobuntu (i.e. Linux)?

Regarding text directions: I just tested both ChromeVox as well as VoiceOver on this example left elide JS Bin: https://jsbin.com/diqurafute/2/edit?html,css,output Setting text direction via CSS did not seem to have any effect, the voice output worked fine in all cases. dtseng@, could you confirm that screen readers work fine with any text direction now?

ping dtseng@: is it OK to flip text-direction to RTL to visually left-elide text?  we previously reverted some code that did this

https://www.chromium.org/developers/accessibility/chromevox

Screen readers should work fine regardless of text direction.

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

commit 42a5543b03b6b099cc52f6d672250c16b8ace86f
Author: jdoerrie <jdoerrie@chromium.org>
Date: Fri Dec 02 10:09:04 2016

Elide origin URLs from the left

This change elides long origin URLs from the left, so that the high level domain
of the domain remains visible. This is beneficial for security reasons.

BUG= 620007 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/42a5543b03b6b099cc52f6d672250c16b8ace86f/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.html

Marking this as fixed, the recently landed CL implements a CSS only solution to the problem.