16797 - [DOGFOOD] tree view for file:// urls not showing content

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[Judson Valeski]

The file channel stuff has been changing recently (I think). Sounds like maybe
an OnData or OnStop isn't getting through.

Comment 1

[leger]

Can you please explain to us WHY you think this is dogfood?  We'll check in on
this bug again tomorrow 5pm.  Thanks!

Comment 2

[Chris Waterson]

*** Bug 15925 has been marked as a duplicate of this bug. ***

Comment 3

[leger]

Not needed for dogfood, putting on PDT-

Comment 4

[Judson Valeski]

*** Bug 17523 has been marked as a duplicate of this bug. ***

Comment 5

[Tom Everingham]

This is not working under Linux either.   If I type in file:/u,  I get a blank
page.  If I type in /u or /u/ the browser generates an http url.

Comment 6

[Warren Harris]

This is because the webshell stuff should try http:/u, and if that fails try
file:/u. What happens if you type file:/u? Does that load? If not, then there's
another problem in necko beyond the webshell stuff.

Comment 7

[Warren Harris]

I just tried typing file://c|/ into the location bar and didn't get a file list
that way either, so I suspect that there's more to this than just trying the
file: protocol.

It could be related to the nsFileSpec bug that's reported elsewhere (bug
18149).

Comment 8

[Chris Waterson]

I dug a bit deeper, and believe that this is related to changes introduced in
r1.33 of nsFileTransport.cpp. Specifically, with this change, it seems like we
place too much credence in a file's length as reported by stat(). We need to be
able to handle files who have no size (e.g., stuff in the /proc filesystem),
but can generate a content stream. The HTTP Index stuff used to do this: it
reports a directory's "content length" as zero, but then coughs up bytes when
asked.

Comment 9

[Chris Waterson]

Attachment: proposed fix

Comment 10

[Chris Waterson]

warren: take a look at the fix and let me know if it looks ok. The idea is to
allow mTransferAmount to be zero, in which case, we'll just treat the stream as
being done when we've got no more data to read out of it; i.e., writeAmt == 0
from the mBufferOutputStream.

I removed the terminiation condition wheremTransferAmount == 0, because this
should (?) be covered by writeAmt == 0. I guess that this could cause an extra
pass through the read loop, though. We could further optimize by maintaining
some more state. Is it worth it?

Comment 11

[Judson Valeski]

I need the ability to pass -1 into the AsyncRead() method as the read amount. We
used to do this right?

Comment 12

[Paul MacQuiddy]

verified

Comment 13

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.