InformAction Forums

That's what HttpFox shows:

Sent Received Meth. Result Type URL
442 35402 GET 200 application/pdf (NS_ERROR_ABORT) http://www.xxx/yyy.pdf
442 0 GET (Error) NS_ERROR_DOCUMENT_NOT_CACHED http://www.xxx/yyy.pdf
485 35402 GET 200 application/pdf http://www.xxx/yyy.pdf

And yes, the plugin works.
I tried it with two different files.

Sorry, the unfinished preview was submitted

I should explain, that first load isn't aborted by NoScript even if it's a 1 MB file. And I'm on dial-in, where the download lasts for ever...

Still

Mc wrote:And yes, the plugin works.

How do you verify this? I disabled placeholders, and all I get is a white page.
Are you getting anything different?

Mc wrote:That's what HttpFox shows

HttpFox lies
When a request is aborted before the response data starts to be processed (like it happens for late post-headers blocking in NoScript), it reports as "Received" the whole byte count declared in the "Content-length" header, rather than the bytes actually received, because it had no chance to actually hook a progress listener yet.
If you sniff the real TCP traffic with wireshark or another packet sniffer, you'll notice that no more than 32KB (Gecko's read buffer) are actually read, i.e. the bare minimum needed to read the HTTP header and guess what kind of content we're going to handle (or kill, in NoScript's case).
Even in HttpFox, you can easily tell the difference between an aborted and a successful request in terms of bytes transferred by observing the byte counter rolling on this 2 megabytes PDF.
Or you can just have fun with this fake pdf, which according to HttpFox is 48KB when whitelisted and 2 Gigabytes when aborted

Oh dear, weird.
Yesterday it worked like I told you, even after several restarts of Fx. My eyes didn't lie when I saw it loading 1MB before the placeholder came up.
But today after a system restart it works like it should. The placeholder comes up at once. And yes, HttpFox lies

1.9.7
Still this yahoo mail pdf download is unresolved.I have to get in only through the context >> blocked objects. I hope this thing is sorted out soon.

nagan wrote:I have to get in only through the context >> blocked objects.

Are you blocking FRAMES/IFRAMES?

dhouwn wrote:

nagan wrote:I have to get in only through the context >> blocked objects.

Are you blocking FRAMES/IFRAMES?

I am not blocking FRAMES/IFRAMES.

Giorgio ,is this not a priority now?

nagan wrote:Giorgio ,is this not a priority now?

Not exactly, since it always worked that way for Yahoo! Mail attachments.
If it behaved better (simpler) for you, it was probably configuration dependent (an extension conflict, maybe?)
Anyway I may have a little idea on how to improve this: if it works, it will be in next development build.

Please check latest development build 1.9.7.2.

There is a slight improvement but then.... I get the file saving box alert even before I click the "download file" link after the AV check. If I still click the "download file" the save file box alert is repeated again (that is totally 2 alerts..)

So something is wrong somewhere...NS is in a "hurry" mode?

I have always gotten the initial (automatic) popup dialog once you clicked the 'paperclip' & the file was scanned.

And now (different) from before, I also will get an expected popup dialog if I were to manually click Download File (without having to deal with an "Unblock" menu item).
(The only reason I could see to deal with 'Download File' would be if you had dismissed the earlier automated popup dialog or if you wanted to download again).

So to me, it looks to be working as expected.

It is not NoScript that is causing the initial automatic popup dialog, it is the fact that you have Allowed yahoo.com (to run JavaScript). If you do not allow yahoo.com you will see you do not get the initial popup. Further you will notice that the virus scan & the reaction to clicking 'Download File' is exponentially quicker. (Maybe that last statement is just a fluke in yahoo's overall response.)

Though I have generated an error, at which point the 'Download File' not longer works: (This "Line: 1" is one huge line.)

Now I'm not getting Download File to work at all, so not sure at this point if it is only a yahoo issue or NoScript related too?

What I think I did, along the line, was to click the Download File multiple times in succession. And it worked & worked & worked, ... & at some point it stopped working, & it was then that I noticed the above error. Reopening the message with the pdf, & going through the routine again, & the Download File is still not working. You can see if "fire", but no download dialog ensues.

If I log out of yahoo ... log back in, & I get the same results.

So I'd have to disable (uninstall in this case) NoScript to see if it might be a NoScript issue (but cannot do that at the moment).

And in a different (SeaMonkey 1.1.17) Profile, I am not able to replicate the error. Not understanding this, ABE locks up Fx2 for the duration of dns query, perhaps what I saw was related to that (though in the second Profile I did test with ABE both enabled & disabled).

Yeah ,checked with a clean profile. It seems the yahoo site is a little impatient and forces the choice on the user even before the user clicks "Download file" and has nothing to do with NS.

The earlier bug is gone now.

And 'Download File' remains broken in my main Profile, even after browser restart .

In addition to the Error: O.contentWindow has no properties above: Got it.

This occurs if IFRAME (specifically & as opposed to FRAME) is blocked.

therube wrote:And 'Download File' remains broken in my main profile, even after browser restart .

Are you blocking iframes?