On Mon, May 26, 2014 at 04:27:52PM +0200, Fabian Raetz wrote: > On Wed, May 21, 2014 at 06:42:41PM +0200, Fabian Raetz wrote: > > Hi folks, > > > > i'm seeing a weird behavour in Firefox 30 beta (it was there already in > > 29 though). > > > > When downloading something, nothing happens. I opened the > > "Show all Downloads" Library and saw that there is an entry > > for the downloaded file but either it is marked as "Failed" or as > > "Canceled". After clicking the Retry button, the Download starts as > > expected. > > > > I've recorded a small video which demostrates the issue. > > http://mischi.selfhost.bz/Firefox30beta-SafeMode-Download-issue.webm > > > > > > My first suggestion was, that some AddOns like Vimperator messed > > somthing up. But after installing the Beta i reseted all and started > > in Safe Mode. > > > > Does anyone else seeing this? > > > > > > Regards, > > Fabian > > > > Hi, > > i've started looking through the firefox codebase to eventually fix the > bug. Later today i will create a bug report upstream. > > I'm looking for some help in interpreting my test results because > they make not much sense to me (My C skills are not that good atm). > > So any help in understanding this further is highly appreciated :) > > > So here's what i found so far: > > In Firefox are basically two components responsible for downloading > files. When downloading files via clicking on an url the relevant > component is the "DownloadLegacyTransfer" which can be found in the file > "toolkit/components/jsdownloads/src/DownloadLegacy.js" and this is > the component where things go wrong. > > "DownloadLegacyTransfer" is a XPCOM Component and is used from C++ code. > > The C++ code calls the "init" method which is implemented in javascript > and looks like this: > > toolkit/components/jsdownloads/src/DownloadLegacy.js:208 > ------------------------------------- > init: function DLT_init(aSource, > aTarget, > aDisplayName, > aMIMEInfo, > aStartTime, > aTempFile, > aCancelable, > aIsPrivate) > { > .... > } > ----------------------------------- > > The parameter "aIsPrivate" is a boolean which should be true > when we are in a private browsing session otherwise "aIsPrivate" > should be false. > > Badly, on OpenBSD "aIsPrivate" is somehow always true!!! > This leads to all kind of wrong decisions in the following codepath. > > Basically all downloads are associating with a "private session", > and these "private" downloads will not be visualized in a "public > session". > > This behaviour can be verified by opening a second Firefox Window in > "private session" mode. Now download a file in either the > normal or the "private session" window and you will see, that the download > is always visualized in the "private session" window. > > -- > > So i dig into the C++ side to see why "aIsPrivate" is always true. > To my surprise the value on the C++ side is correct and is false > when not in a "private session". > > Here the relevant code snippet that calls the "init" method: > > uriloader/exthandler/nsExternalHelperAppService.cpp:2078 > ----------------------------------- > ... > > rv = transfer->Init(mSourceUrl, target, EmptyString(), > mMimeInfo, mTimeDownloadStarted, mTempFile, this, > channel && NS_UsePrivateBrowsing(channel)); > > ... > ----------------------------------- > > So on the C++ side "aIsPrivate" is false and somehow the JS side > retrives true. Curious! :) > > To ease debugging i stored the aIsPrivate expression in a temp variable: > > ----------------------------------- > ... > > bool mytest = false; > > ... > > mytest = channel && NS_UsePrivateBrowsing(channel); > printf("Right before init: %d\n", mytest); > rv = transfer->Init(mSourceUrl, target, EmptyString(), > mMimeInfo, mTimeDownloadStarted, mTempFile, this, > mytest); > > ... > ----------------------------------- > > Huh, after this change, i see correct results on the JS side. > "aIsPrivate" is now false as it should be. o0 > > But not always! I test with different files from a OpenBSD snapshot > directory. To me it looks like "aIsPrivate" is set correctly except in cases > where the downloaded file is too "small". > > Curious too! > > So when downloading base.tgz, install.iso, install.fs they have a > correct "aIsPrivate" value of false (Both on C++ and JS side). > > Downloading xetc.tgz or etc.tgz they have a wrong "aIsPrivate" value of > true. (On the C++ side, "aIsPrivate" is false as expected, only the JS > side sees a wrong "aIsPrivate" of true like before my change.) > > > So something is weird. Any suggestions what could be wrong > or what to include in the bug report?
Nice findings! Re-thinking about this, i really think this might loosely be related to something called OS.File (which, as you can guess by the name, is a JS API to deal with filesystem access... cf https://developer.mozilla.org/en-US/docs/JavaScript_OS.File) which has seen some changes in the past releases (as has seen the download manager, which iirc got mostly rewritten, so new bugs might have been introduced). Since this API/Implem uses a lot underlying OS-specific filesystem API, there might be something here dealing with file size estimates (totally clueless hint, since your findings seem to say this is related to file size) that is badly done on OpenBSD, and "working" on supported platforms. Try looking there, and if you find something, followup on https://bugzilla.mozilla.org/show_bug.cgi?id=971897 which is already opened for that issue. Either way, report your findings about the codepath there to raise awareness on this upstream. Landry
