Closed
Bug 997519
Opened 10 years ago
Closed 10 years ago
Cannot view resource://, chrome:// or any other jar:file://.../omni.ja!/.../ urls as directory lists
Categories
(Core Graveyard :: Networking: FTP, defect)
Tracking
(firefox28 unaffected, firefox29 unaffected, firefox30 unaffected, firefox31- affected)
RESOLVED
FIXED
mozilla31
Tracking | Status | |
---|---|---|
firefox28 | --- | unaffected |
firefox29 | --- | unaffected |
firefox30 | --- | unaffected |
firefox31 | - | affected |
People
(Reporter: lp_, Assigned: emk)
References
Details
(Keywords: regression)
Attachments
(1 file)
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
Blocks: 948901
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: FTP
Ever confirmed: true
Product: Firefox → Core
Comment 2•10 years ago
|
||
Umm, Neil, any idea what's wrong here?
status-firefox28:
--- → unaffected
status-firefox29:
--- → unaffected
status-firefox30:
--- → unaffected
status-firefox31:
--- → affected
tracking-firefox31:
--- → ?
Flags: needinfo?(neil)
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Comment 3•10 years ago
|
||
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.
Flags: needinfo?(neil)
Assignee | ||
Comment 4•10 years ago
|
||
I couldn't reproduce it either. We will need a more detailed STR.
Keywords: steps-wanted
Comment 5•10 years ago
|
||
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. :-\
Comment 6•10 years ago
|
||
(In reply to neil@parkwaycc.co.uk 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?
Flags: needinfo?(neil)
Comment 7•10 years ago
|
||
jar:file:///Applications/FirefoxNightly.app/Contents/MacOS/omni.ja!/ also shows no listing, while that is the correct path to my omni.ja file.
Updated•10 years ago
|
Keywords: steps-wanted
Summary: Cannot view resource:// urls as directory lists → Cannot view resource://, chrome:// or any other jar:file://.../omni.ja!/.../ urls as directory lists
Assignee | ||
Comment 8•10 years ago
|
||
Thank you, confirmed with a jar: URL.
Assignee | ||
Comment 9•10 years ago
|
||
mTextToSubURI->UnEscapeAndConvert() failed because encoding was an empty string and the scheme is not file. GetOriginCharset() will not return a meaningful value here.
Comment 10•10 years ago
|
||
(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?
Assignee | ||
Comment 11•10 years ago
|
||
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 12•10 years ago
|
||
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+
Updated•10 years ago
|
Flags: needinfo?(neil)
Assignee | ||
Comment 13•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b79f456a5566
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Comment 14•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b79f456a5566
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Comment 15•10 years ago
|
||
Gijs, Do you still think this warrants tracking?
Flags: needinfo?(gijskruitbosch+bugs)
Updated•10 years ago
|
QA Whiteboard: [good first verify]
Updated•1 month ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•