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?


Regards,
Fabian





Reply via email to