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

Categories

(Core :: Networking: FTP, defect)

31 Branch
defect
Not set

Tracking

()

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
Umm, Neil, any idea what's wrong here?
Flags: needinfo?(neil)
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
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)
I couldn't reproduce it either. We will need a more detailed STR.
Keywords: steps-wanted
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 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)
jar:file:///Applications/FirefoxNightly.app/Contents/MacOS/omni.ja!/

also shows no listing, while that is the correct path to my omni.ja file.
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
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?
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+
Flags: needinfo?(neil)
https://hg.mozilla.org/integration/mozilla-inbound/rev/b79f456a5566
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/b79f456a5566
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Gijs, Do you still think this warrants tracking?
Flags: needinfo?(gijskruitbosch+bugs)
It's fixed, so, meh. :-)
Flags: needinfo?(gijskruitbosch+bugs)
Not tracking at this some because meh. :-)
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.