997519 - Cannot view resource://, chrome:// or any other jar:file://.../omni.ja!/.../ urls as directory lists

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Liu Ping]

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.

Comment 1

[YF (Yang)]

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

Comment 2

[:Gijs (he/him)]

Umm, Neil, any idea what's wrong here?

Comment 3

[[e-mail]]

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.

Comment 4

[Masatoshi Kimura [:emk]]

I couldn't reproduce it either. We will need a more detailed STR.

Comment 5

[:Gijs (he/him)]

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

[:Gijs (he/him)]

(In reply to [e-mail] 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?

Comment 7

[:Gijs (he/him)]

jar:file:///Applications/FirefoxNightly.app/Contents/MacOS/omni.ja!/

also shows no listing, while that is the correct path to my omni.ja file.

Comment 8

[Masatoshi Kimura [:emk]]

Thank you, confirmed with a jar: URL.

Comment 9

[Masatoshi Kimura [:emk]]

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

[:Gijs (he/him)]

(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 11

[Masatoshi Kimura [:emk]]

Attachment: Ensure that an valid encoding will be passed to nsTextToSubURI::UnEscapeAndConvert()

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.

Comment 12

[[e-mail]]

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.)

Comment 13

[Masatoshi Kimura [:emk]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b79f456a5566

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b79f456a5566

Comment 15

[Benjamin Kerensa [:bkerensa]]

Gijs, Do you still think this warrants tracking?

Comment 16

[:Gijs (he/him)]

It's fixed, so, meh. :-)

Comment 17

[Benjamin Kerensa [:bkerensa]]

Not tracking at this some because meh. :-)