Closed Bug 997519 Opened 6 years ago Closed 6 years ago
Cannot view resource://, chrome:// or any other jar:file://.../omni
.ja!/.../ urls as directory lists
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140416030202 Steps to reproduce: resource:// URLs, such as resource:///modules/ or resource://gre/modules/, now give a blank page. Actual results: view source showed that the contents are right, there is a list of files, but cannto show up. Browser console error: The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. Expected results: It should give a directory list page, like a file folder.
Regression-range: Last good revision: 6fa163ff81a3 (2014-03-28) First bad revision: 4f3443da36a1 (2014-03-29) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa163ff81a3&tochange=4f3443da36a1 No more inbounds to bisect Last good revision: a4c9a284e014 First bad revision: b2f9a0080f9c Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a4c9a284e014&tochange=b2f9a0080f9c
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: FTP
Ever confirmed: true
Product: Firefox → Core
Umm, Neil, any idea what's wrong here?
I can't reproduce this. The resource: URL displays correctly, there is no warning in the console, and the document has a <meta charset="UTF-8"> element. But then again I'm using an en-US self-build of Firefox.
I couldn't reproduce it either. We will need a more detailed STR.
Just loading a resource:/// or resource://gre/ (or those + "modules/") from the nav bar on a regular en-US nightly from the 15th or 16th shows a blank page, on OS X. I'm not really sure why you can't reproduce. :-\
(In reply to email@example.com from comment #3) > I can't reproduce this. The resource: URL displays correctly, there is no > warning in the console, and the document has a <meta charset="UTF-8"> > element. > > But then again I'm using an en-US self-build of Firefox. Can you try to reproduce on an actual nightly so it's using omni.ja instead of regular disk folders?
jar:file:///Applications/FirefoxNightly.app/Contents/MacOS/omni.ja!/ also shows no listing, while that is the correct path to my omni.ja file.
Summary: Cannot view resource:// urls as directory lists → Cannot view resource://, chrome:// or any other jar:file://.../omni.ja!/.../ urls as directory lists
Thank you, confirmed with a jar: URL.
mTextToSubURI->UnEscapeAndConvert() failed because encoding was an empty string and the scheme is not file. GetOriginCharset() will not return a meaningful value here.
(In reply to Masatoshi Kimura [:emk] from comment #9) > mTextToSubURI->UnEscapeAndConvert() failed because encoding was an empty > string and the scheme is not file. > GetOriginCharset() will not return a meaningful value here. If it has ideas about file URI encodings, can't we just use the nested scheme for jar URIs?
nsStandardURL will return "UTF-8" if the origin charset is empty. https://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp?rev=8e20983ae82d#1107 But jar: URIs will not. https://mxr.mozilla.org/mozilla-central/source/modules/libjar/nsJARURI.cpp?rev=1123c64bca9e#447 I have changed the caller to minimize the impact.
Attachment #8408325 - Flags: review?(neil)
Comment on attachment 8408325 [details] [diff] [review] Ensure that an valid encoding will be passed to nsTextToSubURI::UnEscapeAndConvert() (I guess moving the declaration of the variable nearer to its use makes sense.)
Attachment #8408325 - Flags: review?(neil) → review+
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Gijs, Do you still think this warrants tracking?
It's fixed, so, meh. :-)
You need to log in before you can comment on or make changes to this bug.