console error on every ftp site
Reported by
pdk...@gmail.com,
May 28 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36 Steps to reproduce the problem: 1. ftp://ftp.adobe.com What is the expected behavior? What went wrong? (index):349 Unexpected condition on ftp://ftp.adobe.com/: Could not find value for language Did this work before? Yes Chrome version: 51.0.2704.63 Channel: stable OS Version: Ubuntu 14.04 Flash Version: The listing still works fine.
,
May 31 2016
Forward to i18n for triage, it looks like "<html i18n-values="dir:textdirection;lang:language">" in net/base/dir_header.html should be substituted by correct language.
,
Jun 2 2016
,
Jun 2 2016
This appears to have never worked, since it was landed 16 months ago in https://codereview.chromium.org/880313002. [+dbeam]: FTP pages are not WebUI pages. Was that change accidental, or should it have the platform language header attached? Note that FTP gets a directory listing from a remote site, with an unclear encoding scheme, though it also includes localized text for the title and column names. Given that this has been broken so long, doesn't really seem like a regression, and lowering the priority as well.
,
Jun 2 2016
hmmmm, there was previously a "textdirection" key, which is usually set at the same time as the "language" key, so sorry if I missed this subtle difference. i wonder where/how the "textdirection" key is being set if information about the "language" is not available (typically the UI lang has a default RTL-ness that we use to flip the page or not). followup question: are these pages still/actually translated? if not: we can set lang="en" dir="ltr" and call it day. anyways, i guess there are no try jobs that open these pages because otherwise I believe console errors would cause a test to fail (this may only be in some browser_tests, though). [1] https://codereview.chromium.org/880313002/diff/100001/chrome/renderer/resources/error_app.html?context=&column_width=80&tab_spaces=8 [2] https://codereview.chromium.org/880313002/diff/100001/chrome/renderer/resources/neterror.html?context=&column_width=80&tab_spaces=8
,
Jun 2 2016
,
Jun 2 2016
Yea, I can easily see how you missed that these weren't WebUI pages. Sorry for not being clearer, the problem is actually with https://codereview.chromium.org/880313002/patch/100001/110101 - it looks like you updated the error pages correctly. If you go to a sample ftp size (Say ftp://ftp.adobe.com/), you'll see: "Index of /" "Name Size Date Modified" <file list> "Index of", "Name", "Size", "Date Modified" are all internationalized based on the client's locale. Everything else are file/path names from the server. It looks to me like the language direction currently comes from the client's locale: chrome/common/net/net_resource_provider.cc The file names themselves have an indeterminant encoding (Aren't ancient protocols great?). It does look like we have some browser tests: chrome/browser/net/ftp_browsertest.cc
,
Jun 2 2016
,
Jun 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d0039e587748cb814324eefb9941a4706ebc5c2c commit d0039e587748cb814324eefb9941a4706ebc5c2c Author: dbeam <dbeam@chromium.org> Date: Tue Jun 07 02:58:10 2016 Fix FTP directory listing page error by adding "language" key Also shuffle some test code around so bugs like this can be more easily noticed by bots. R=mmenke@chromium.org BUG= 615626 Review-Url: https://codereview.chromium.org/2032903004 Cr-Commit-Position: refs/heads/master@{#398212} [modify] https://crrev.com/d0039e587748cb814324eefb9941a4706ebc5c2c/chrome/common/net/net_resource_provider.cc
,
Jun 10 2016
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kavvaru@chromium.org
, May 30 2016Components: Platform>DevTools Internals>Network>FTP
Labels: M-53 hasbisect OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)