Closed
Bug 506491
Opened 15 years ago
Closed 15 years ago
Download Manager opens 'Blank' - intermittent - Error: gStr.timeUnits is undefined and download is null
Categories
(Core :: JavaScript Engine, defect, P2)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: jmjjeffery, Assigned: jorendorff)
References
Details
(Keywords: intermittent-failure, regression, Whiteboard: , [nv])
Attachments
(4 files)
Opening the DM at times results in a Blank window, with no previous history showing. Failing in today's nightly build with changeset: http://hg.mozilla.org/mozilla-central/rev/78fa6be2aac1 Sorry for being vague, but I 'think' its ok with changeset: http://hg.mozilla.org/mozilla-central/rev/b8c752d9bc65 When the DM opens blank I also see these errors in Console2: DownloadUtils.jsm: Couldn't get string 'units' from property '' DownloadUtils.jsm: Couldn't get string 'timeFewSeconds' from property '' others are reporting the issue in the nightly build thread on MZ: http://forums.mozillazine.org/viewtopic.php?f=23&t=1379845
Reporter | ||
Comment 1•15 years ago
|
||
OK, just got it to fail using changeset: http://hg.mozilla.org/mozilla-central/rev/b8c752d9bc65 This in Console2: Error: gStr.timeUnits is undefined Source file: file:///J:/Program%20Files%20(x86)/Minefield/modules/DownloadUtils.jsm Line: 472 ---------- DownloadUtils.jsm: Couldn't get string 'transferNoTotal' from property '' ---------- Error: download is null Source file: chrome://mozapps/content/downloads/DownloadProgressListener.js Line: 78
Reporter | ||
Comment 2•15 years ago
|
||
Waiting confirmation from others in the build thread on MZ, but it now appears that with HTML5 = enabled, the fails occur. Its very intermittent, so I'm thinking it must be a weird timing issue maybe ?
Reporter | ||
Comment 3•15 years ago
|
||
Not HTML5 related, others are reporting still getting blank DM on occasion. I can repo it at times: Set downloads in options to 'always ask where to save...' Click a file to download, when the Windows Explorer opens, create a new sub-folder in a folder. Click 'save file' The DM will open 'Blank' at times.. not 100% however, sometimes it works OK.
Updated•15 years ago
|
Summary: Download Manager opens 'Blank' - intermittant → Download Manager opens 'Blank' - intermittent
Updated•15 years ago
|
Flags: blocking1.9.2?
Comment 4•15 years ago
|
||
Seeing this on Linux trunk. DownloadUtils.jsm: Couldn't get string 'timeUnknown' from property '' DownloadUtils.jsm: Couldn't get string 'units' from property ''
OS: Windows Vista → All
Hardware: x86 → All
Comment 5•15 years ago
|
||
Didn't any of the automated tests catch this? Seems like they didn't. :-(
Comment 6•15 years ago
|
||
(In reply to comment #5) > Didn't any of the automated tests catch this? Seems like they didn't. :-( Maybe the test boxes aren't seeing it? I don't follow how those errors are coming up though. Is this with chrome JIT on or off?
Comment 7•15 years ago
|
||
I don't have it turned on. javascript.options.jit.chrome;false
It's not showing the first download I initiate, but it shows the next ones. But then if I search in the download list, it goes blank again, even when I cancel the search. In my about:config : html5 disabled, both jit options false. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090727 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090727044731
Comment 10•15 years ago
|
||
Do people also see the status bar shows "# downloads (undefined)" ? I ran in to this just now, but I can't reproduce it.. I did try Cu.importing and calling various functions just to try debugging. DownloadUtils.getTimeLeft(-1) results in.. Warning: reference to undefined property gStr.timeUnknown DownloadUtils.getTimeLeft(1000).. Error: gStr.timeUnits is undefined So it's not just the array strings (units/timeUnits) that are failing to load. Somehow loading the strings failed.. ? I tried manually loading the strings from the Error Console and that seemed to work fine: x = Components.classes["@mozilla.org/intl/stringbundle;1"].getService(Components.interfaces.nsIStringBundleService).createBundle("chrome://mozapps/locale/downloads/downloads.properties").GetStringFromName; x("timeUnknown")
Reporter | ||
Comment 11•15 years ago
|
||
In reply to comment #10 , yes the status-bar is (undefined) when the issue of coming up 'blank' arises.
Comment 12•15 years ago
|
||
I also see the "(undefined)" in the status bar. And in the Downloads dialog I don't see any transfer rate below the progress bar.
Comment 13•15 years ago
|
||
This file hasn't changed since 5/12/2009, so did something break importing JavaScript modules maybe?
With comment 11 still happening, makes me wonder how bug 487638 was tested prior to checkin.
Comment 15•15 years ago
|
||
(In reply to comment #14) Afaict, bug 487638 is unrelated, it's dealing with page loads, not downloads in the dm.
Reporter | ||
Comment 16•15 years ago
|
||
un-scientific testing I have found what I believe is a pattern in getting the DM to open blank. Seems to me that its a start-up initialization issue perhaps. Open Minefield several tabs, I have 16. Once ALL tabs are loaded open the DM, note: its blank. Close/Open Minefield again and as soon as the UI appears hit Ctrl+J, note the DM will fill as it should. I have repeated this about 6 times, and every-time I let all the tabs fill, the DM is blank. I have no clue how to trace startup steps/routines.
Comment 17•15 years ago
|
||
Could a tracemonkey merge possible have broken js module files?
Comment 18•15 years ago
|
||
Once the DM "blank" window occurs, if you then download something it appears in the blank window without any download progress indicators. If the DM window then gets closed, upon re-opening the latest entry that had appeared in DM has also been removed from the window and you're presented with a "blank" window again. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090729 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090729045158
Comment 19•15 years ago
|
||
Simplist would be to backout some patches and to upload the builds to tryserver for testing.
Comment 20•15 years ago
|
||
I see this -- toggling jit off didn't help. Last two nightlies, IIRC. Can anyone bisect down to a particular cset? /be
Reporter | ||
Comment 21•15 years ago
|
||
Making some progress on the regression range. Changeset: http://hg.mozilla.org/mozilla-central/rev/566ec4a87812 Nightly OK Changeset: http://hg.mozilla.org/mozilla-central/rev/f353d2b637b3 is Bad Still a large range of patches landed, still trying to narrow it down.
Reporter | ||
Comment 22•15 years ago
|
||
Best range I can get for the builds I happened to download: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-07-24+01%3A45%3A00&enddate=2009-07-25+01%3A15%3A00
Comment 23•15 years ago
|
||
(In reply to comment #22) > Best range I can get for the builds I happened to download: In order to get a foolproof range, could you please post the changesets that these builds were built from?
Reporter | ||
Comment 24•15 years ago
|
||
OK, more.... cset http://hg.mozilla.org/mozilla-central/rev/9dfacae57238 is OK cset http://hg.mozilla.org/mozilla-central/rev/7fc462364b5e is broken Leaving cset: http://hg.mozilla.org/mozilla-central/rev/a928ab3ec436 as the range, which I can't find an hourly build for... 238 changeset I used zip build from here: http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1248463050-20090724121730-9dfacae57238-firefox-3.6a1pre.en-US.win32.zip b53 changeset I used zip build from here: http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1248464824-20090724124704-7fc462364b5e-firefox-3.6a1pre.en-US.win32.zip Note for convenience at least for me, I'm only using the last 3 letter/numbers of the changeset, full changeset is above.
Comment 25•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9dfacae57238&tochange=7fc462364b5e
Updated•15 years ago
|
Assignee: nobody → general
Component: Download Manager → JavaScript Engine
Product: Toolkit → Core
QA Contact: download.manager → general
Comment 26•15 years ago
|
||
Does tracemonkey tip show the problem? /be
Comment 27•15 years ago
|
||
I'm seeing this in both TM tip and trunk nightlies but it's very random. Haven't been able to nail down STR. :-( Just encountered this issue downloading the latest trunk hourly .zip file using build: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090730044307 ~B
Comment 28•15 years ago
|
||
Consistently reproduces for me going to http://taossa.com/ and clicking on the "here" link in the "BlackHat 2009 Whitepaper: Attacking Interoperability" blog item (dated July 29th, 2009). Interesting to note that clicking on a registration-walled download-this-PDF link (haven't looked at how it works, looks like a CGI -- not a .pdf file link) in mail I regularly get, which opens a new tab per the Firefox pref default, does open the download manager, download the PDF, and successfully render the download manager's list of recent downloads. /be
Comment 30•15 years ago
|
||
Happened to me on windows 7, fresh profile, first download. The first download was the windows 7 sdk from: http://www.microsoft.com/downloads/details.aspx?familyid=a91dc12a-fc94-4027-b67e-46bab7c5226c&displaylang=en Will try to see if it is reproducible after my download completes. Sorry for the dupe.
Comment 31•15 years ago
|
||
(In reply to comment #30) > Happened to me on windows 7, fresh profile, first download. The first download > was the windows 7 sdk from: > http://www.microsoft.com/downloads/details.aspx?familyid=a91dc12a-fc94-4027-b67e-46bab7c5226c&displaylang=en Not related to this bug, but if you have win7 RC, you should get the newer SDK for the RC. It contains a number of fixes since the beta: http://www.microsoft.com/downloads/details.aspx?familyid=F75F2CA8-C1E4-4801-9281-2F5F28F12DBD&displaylang=en
Comment 32•15 years ago
|
||
#10 I'm seeing the "undefined" and I believe I saw the count say "2" when it should have been "1". So the count was OUT OF DATE. The out-of-dateness may be significant. This on Linux freshly built (2 days ago) from mozilla-central on Ubuntu 9.04 Linux.
Comment 33•15 years ago
|
||
> TEST-INFO | chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_bug471962.js | Console message: [JavaScript Error: "docToSave is null" {file: "chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_bug471962.js" line: 281}] > TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_bug471962.js | Timed out http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249040145.1249042129.24012.gz#err2
Comment 34•15 years ago
|
||
The download window works again for me on the past two nightly trunks. I don't know if that is circumstantial or if another patch fixed this regression. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090731044744 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090801042759
Comment 35•15 years ago
|
||
(In reply to comment #34) > The download window works again for me on the past two nightly trunks. I don't > know if that is circumstantial or if another patch fixed this regression. > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 > Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090731044744 > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 > Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090801042759 the same for me on linux. I wonder which checkin fixed this..
Comment 36•15 years ago
|
||
confirmed fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 Minefield/3.6a1pre ID:20090731044744
Comment 37•15 years ago
|
||
It does appear to be "fixed" but when I stop and restart a download I see the following in the error console: Error: aText is undefined Source File: file:///C:/Program%20Files/Firefox%20Trunk/firefox/modules/DownloadUtils.jsm Line: 493 DownloadUtils.jsm: Couldn't get string 'timeLeftSingle' from property '' DownloadUtils.jsm: Couldn't get string 'timeFewSeconds' from property '' BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090801081931 ~B
Comment 38•15 years ago
|
||
It is NOT fixed, I see blank DM still!!
Reporter | ||
Comment 39•15 years ago
|
||
Until someone that can read patches and understand the code and analyze which patch in the list given in comment #25 , its not going to magically go away or fix itself. Its down to making a best guess as to which patch broke the DM or backing out stuff and checking. Both a slow process..
Comment 40•15 years ago
|
||
I wonder if the problem could ultimately be the declaration "let kStrings = {...}" at lines 81-96. There's an extra, seemingly unnecessary, trailing "," after "timeUnits: ["seconds", "minutes", "hours", "days"]" (i.e. line 95). I deleted that extra comma and so far no more problems. Of course, this could all be coincidence.
Comment 41•15 years ago
|
||
Oops. I should have mentioned that the file is \modules\DownloadUtils.jsm.
Comment 42•15 years ago
|
||
I am no programmer, but that comma fixed it for me also, none errors in error console while downloading now.. Must test more but looks promising...
Comment 43•15 years ago
|
||
And because I am no programmer, makes me wonder what has changed because that comma is there in Firefox 3.5 version of DownloadUtils.jsm as well, and it works as all know?
Comment 44•15 years ago
|
||
Heh... of course it had to be a coincidence. I'm getting desperate. :-( The comma is necessary. Ignore me.
Comment 45•15 years ago
|
||
That comma did something but just now my DM is empty again... Downloads are timed on status bar though... And that DownloadUtils.jsm did not change when DM broke...
Comment 46•15 years ago
|
||
Download Manager is indeed still blank (sometimes) with latest hourly on Vista.
Comment 47•15 years ago
|
||
I still have the DM displaying files, but it doesn't show anything about progress changes, including only updating the progress bar every few minutes. Like in the earlier comments, I get these errors repeatedly in the JS Console "aText is undefined DownloadUtils.jsm Line 493" and "gStr.timeUnits is undefined DownloadUtils.jsm Line 477" I don't get "download undefined", instead "One active download (Unknown time remaining)" on a file with a known size. I wonder if something was changed in another file which hands arguments to a function like getDownloadStatus(), that function is the one--if I read the code correctly--should generate arguments that ultimately define aTime, and it's called by another file (I just don't know which one...).
Comment 48•15 years ago
|
||
Can anyone get some reliable steps to reproduce here? When it shows blank, is there a workaround (like closing it and opening again, or restarting Firefox?) This is now nominated to block the alpha, sigh.
Priority: -- → P1
Reporter | ||
Comment 49•15 years ago
|
||
(In reply to comment #48) > Can anyone get some reliable steps to reproduce here? When it shows blank, is > there a workaround (like closing it and opening again, or restarting Firefox?) > > This is now nominated to block the alpha, sigh. Sadly, no.. I keep hammering on it trying to find STR, and its a total moving target. It might work 5-6 times in a row, then out of the blue - fail. Sometimes closing/reopening the DM will cause it to refresh and populate, other times it won't populate until close/restart of browser, and even then, I've seen it open blank right off the bat, or sometime later. I can't help but feel strongly there is a race-condition or some javascript getting GC'd or something. There were several landings from TM at noted in the comment #25 , but I'm not a coder, or know anything about localized trees and testing to start doing back-outs...
Comment 51•15 years ago
|
||
Something that could help is to find the regression window using the tracemonkey builds (the ones located on http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-MM-DD-HH-tracemonkey/). That should hopefully find a regression window with less JS related changes than comment 25.
Comment 52•15 years ago
|
||
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=cc066e62c8c5&tochange=64b2ea3926de Those are the tracemonkey changesets from comment 25. So these would be useful builds to check: http://archive.mozilla.org/pub/mozilla.org/firefox/nightly/2009/07/2009-07-21-03-tracemonkey/ http://archive.mozilla.org/pub/mozilla.org/firefox/nightly/2009/07/2009-07-22-03-tracemonkey/ http://archive.mozilla.org/pub/mozilla.org/firefox/nightly/2009/07/2009-07-23-03-tracemonkey/ http://archive.mozilla.org/pub/mozilla.org/firefox/nightly/2009/07/2009-07-24-03-tracemonkey/
Comment 53•15 years ago
|
||
For those experiencing the bug, does restarting Firefox / reducing the number of tabs you have open / opening and closing the download manager fix the problem?
Comment 54•15 years ago
|
||
(sorry for spam, just thought of this) Does clearing the download history and then trying again fix it?
Comment 55•15 years ago
|
||
This is now WFM, before I cleared DM history (but I may have deleted an item or two). Sorry I can't say more. I also lost sessionstore.{js,bak} somehow recently -- I'm running m-c nightlies. /be
Comment 56•15 years ago
|
||
> Does clearing the download history and then trying again fix it?
No.
Comment 57•15 years ago
|
||
I don't know if this is related to this issue but my DM window opens in the upper left hand corner of my screen instead of where I've moved it previously! Basically every now and then the previous DM window state does not persist. I also continue to experience this very random issues of the DM being blank when downloading. BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090806065318 ~B
Comment 58•15 years ago
|
||
(In reply to comment #53) > For those experiencing the bug, does restarting Firefox / reducing the number > of tabs you have open / opening and closing the download manager fix the > problem? Yes, I saw this today with Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre I tried to download a file, empty DM window opened in upper left corner, obviously wrong "1 download (undefined)" text appeared in the status bar and the error console was full of "gStr.timeUnits is undefined" errors (see comment 1 for detailed output). After restarting I tried to download the same file, everything went well and since then I can't reproduce this behaviour. So it seems restarting may help here.
Comment 59•15 years ago
|
||
I can't reproduce using lastest-trunk nightly on Windows using any of the STR provided (by Brendan in comment 28, Clint in comment 30) Those experiencing this issue, please indicate if you're using a latest trunk nightly or not?
Comment 60•15 years ago
|
||
Moving to P2 / not blocking alpha 1 on this. Juan and Clint have both said that while they were experiencing this before, it went away with latest nightlies. I don't think we can close it yet, but I do think we can't block alpha on it, either.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: P1 → P2
Reporter | ||
Comment 61•15 years ago
|
||
Using today's nightly m-c build. I just renamed my downloads.sqlite with Minefield closed, then reopened the browser and the very 1st download attempted popped up with an empty DM. No amount of closes/reopens of the DM would fix the issue or being blank, closed/reopened the browser and now its filled. I then started another download, zip file this time, and boom - blank DM Once the download completed I clicked on the slider link in the lower right corner and low-behold it was filled. Very-very strange and stay's illusive.
Flags: blocking1.9.2+ → blocking1.9.2?
Priority: P2 → P1
Reporter | ||
Comment 62•15 years ago
|
||
Tried all the builds posted in comment #52 and experienced no issues with the DM I'm now using the latest hourly build, and so far have not been able to make it fail :( I'm sure, as soon as I post this it will no doubt act up. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090806092832 cset: http://hg.mozilla.org/mozilla-central/rev/8df64551e067
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Priority: P1 → P2
Comment 63•15 years ago
|
||
(In reply to comment #60) > Moving to P2 / not blocking alpha 1 on this. > > Juan and Clint have both said that while they were experiencing this before, it > went away with latest nightlies. I don't think we can close it yet, but I do > think we can't block alpha on it, either. I'd agree with this. Sorry for the radio silence, I'm way behind on bugmail. I couldn't reproduce it today, much of the testing I've done in the last few days haven't reproduced the problem. So, somehow this went away, but we can't exactly point to why :/
Comment 64•15 years ago
|
||
(In reply to comment #57) > I don't know if this is related to this issue but my DM window opens in the > upper left hand corner of my screen instead of where I've moved it previously! > Basically every now and then the previous DM window state does not persist. > This is a problem I've been experiencing too, occasionally. It's a bit worse in my case: when it does happen, all that shows is the title bar and minimize/maximize/close buttons--all squeezed to minimum width (i.e. just wide enough for the "Downloads" text and the buttons). I then have to resize it. However, the window size issue does not necessarily occur in relation to the blank DM. That being said, both problems appear to have shown up in relatively close proximity, though I can't be precise. As for the blank DM and directly related issue, it still exists. One effect of this bug is that the updater no longer shows progress--even when DM otherwise still shows downloads during any given browsing session. I have a new profile where I have yet to experience the issue, and will do some more testing with it. Is it possible that some data format, schema, or user configurable pref changed within the time frame of the issue?
Comment 65•15 years ago
|
||
can someone zip up a profile where they're getting this somewhat more reproducibly? (Put it somewhere secure if needed) Have you tried closing Firefox, deleting localstore.rdf and reopening? (Sorry those are the two things I'd ask for if I were doing support. Don't mind me if you've tried both.)
Comment 66•15 years ago
|
||
I think it's a timing thing, depending on whether DownloadUtils is loaded in the DM first or in browser.js. It also depends on whether or not there are pending downloads (there can't be any), plus some other stuff I haven't been able to confirm, but I've been able to repro semi-consistently fiddling around with these things. I'll play around a bit more tonight.
Comment 67•15 years ago
|
||
Just noticed something: On the new profile where I wasn't seeing the blank DM, I've just observed the following: I was downloading a 35 MB file while watching a flash video. I browsed for the location to save the file and once DM popped up, the download was listed and the progress bar displayed, but the text read "Unknown time remaining," with bytes indicating 0. Status bar also indicated "Unknown time remaining." At about 30 % or so complete, the timings and bytes showed up and DM was displaying the active download correctly. At the end of the download, during the virus scan phase, the status bar once again showed showed "Unknown time remaining." I repeated the download, saving to a different location, and the exact same thing happened. I tried a third time: exact same thing happened. The link to the file I was downloading is: http://www.tucows.com/preview/611051
Comment 68•15 years ago
|
||
The change that triggered this was http://hg.mozilla.org/mozilla-central/rev/3915e2d2c748 57f03473969d seems to be fine. I can reproduce this with a new profile (on 3915e2d2c748/Linux/x86_64) after enough downloads (of attachment 392745 [details] [diff] [review], for example.)
Blocks: 503080
Comment 69•15 years ago
|
||
This issue has occurred everyday for me at least two times each day. Someone mentioned this before I believe but I deleted my downloads.sqlite and have downloaded more then fifty files today of various sizes (both .exe and .zip) and cannot reproduce this issue anymore. Keeping my fingers crossed! BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090806164927 ~B
Comment 70•15 years ago
|
||
I could reproduce this with 4983120bae8a (when last known regression from Bug 503080 was fixed) although less reliably. Valgrind didn't have any unusual complaints. But I haven't seen this happen with d300a4725056 (last tracemonkey merge) nor dc02eff6d8c0 (3_6a1).
Comment 71•15 years ago
|
||
By the way, my new profile, which wasn't exhibiting the blank DM dialog, finally does suffer from the problem. Therefore, for those who say they no longer experience the problem. I would say that your relief is likely only temporary. So this bug will remain until it's actually fixed.
Comment 72•15 years ago
|
||
A note about this bug should be release notes for alpha 1.
Keywords: relnote
Comment 73•15 years ago
|
||
Since i have been following empty files created with write protection(Windows NTFS), the problem is no longer exists: XPC.mfl XUL.mfl xpti.dat xpti.dat.tmp Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre
Comment 75•15 years ago
|
||
Empty Download Manager in os X as well (10.5.8)
Comment 76•15 years ago
|
||
This reproduces 100% against the WinCE Tegra builds. Adding [nv] whiteboard for tracking. STR: 1) Save file as.. in context menu. (save an image) 2) file saves, but download manager comes up blank Build ID: Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre
Updated•15 years ago
|
Whiteboard: [orange] → [orange], [nv]
Comment 77•15 years ago
|
||
Anybody on the JS team looking at this? We even have the changeset identified that looks to have regressed this (comment 68).
Keywords: qawanted
Comment 78•15 years ago
|
||
Assigning to jorendorff, who checked in the apparently-regressing change.
Assignee: general → jorendorff
Updated•15 years ago
|
Summary: Download Manager opens 'Blank' - intermittent → Download Manager opens 'Blank' - intermittent - Error: gStr.timeUnits is undefined and download is null
Comment 80•15 years ago
|
||
Upgraded to http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1bf16951d1be (Namoroka, first time I saw that name from the nightly update) and this bug started biting again. Not at the moment, though -- unclear why but I see download history again. Will try to debug it. /be
Comment 81•15 years ago
|
||
A bit more info: Even at times when DM is properly displaying downloads, when Software Updater is checking and downloading builds, I get the following (already noted) message in Error Console (16 in rapid succession): Error: aText is undefined Source file: file:///C:/Program%20Files/Internet/firefox/modules/DownloadUtils.jsm Line: 493 And of course, no download progress information shown in the Software Update dialog. Since this bug began, Software Update has not shown progress -- even when Download Manager is showing progress and listing downloads. Maybe the connection between the two will help.
Assignee | ||
Comment 82•15 years ago
|
||
I would like to debug this but I can't reproduce it at all! Probably the best thing would be to team-debug with tchung or someone else who can reproduce it reliably in a debug build. Volunteers?
Comment 83•15 years ago
|
||
(In reply to comment #82) > I would like to debug this but I can't reproduce it at all! > > Probably the best thing would be to team-debug with tchung or someone else who > can reproduce it reliably in a debug build. Volunteers? I'd be happy to help, but the debugging tools on the firefox tegra builds is horrible. For example, there's no command line to output anything to. Dolske has a physical debugger attached to his breadboard, and maybe he can shed some light if his build does the same. But i'll try to see if we can get a debug build up and usable today, and maybe get some data for you.
Comment 84•15 years ago
|
||
I've seen this on Mac laptop, so we shouldn't need to debug this on a Tegra.
Comment 86•15 years ago
|
||
I see this on a Windows 7 desktop pretty consistently as well.
Comment 87•15 years ago
|
||
This bug affects Fennec too, as we use DownloadUtils.jsm in our download manager code. We get "gStr.units is undefined" when attempting to call DownloadUtils.convertByteUnits (http://mxr.mozilla.org/mobile-browser/source/chrome/content/downloads.js#333)
Assignee | ||
Comment 88•15 years ago
|
||
(In reply to comment #84) > I've seen this on Mac laptop, so we shouldn't need to debug this on a Tegra. OK. I'm still in desperate need of a debug buddy, though. The place to put the breakpoint is js_ReportIsNullOrUndefined. (The web being what it is, surely some pages out there would trigger this a lot. But our own chrome JS should not, aside from this bug.)
Comment 89•15 years ago
|
||
When the problem occurs, it's easy to trigger the error from the error console: Components.utils.import("resource://gre/modules/DownloadUtils.jsm"); DownloadUtils.getTimeLeft(4)
Comment 90•15 years ago
|
||
When the problems appear, a DownloadUtils logs the failure message of: DownloadUtils.jsm: Couldn't get string 'timeUnits' from property '' Where "property ''" is actually supposed to print out the property but turns out to be undefined. So then all properties of gStr are undefined because _getStr fails to assign the value: return gStr[name] = typeof value == "string" ? getStr(value) : value.map(getStr); value turns out to be undefined instead of a string or array, so (undefined).map throws _getStr is only called from here, and somehow value disappears but not name? _init: function() { for (let [name, value] in Iterator(kStrings)) let ([n, v] = [name, value]) gStr.__defineGetter__(n, function() gStr._getStr(n, v)); The [n, v] are local copies of [name, value] because name and value will end up as the last [name, value] by the time the getter is triggered. I'm assuming the GC is *not* collecting "n" because it was used in the defineGetter, but "v" isn't so lucky and disappears by the time the getter is executed. When trying to reproduce this issue, I do seem to run in to it more after visiting big pages like amazon.com and digg.com and doing a Weave sync, so those are causing the GC to run.
Assignee | ||
Comment 91•15 years ago
|
||
> function() {
> for (let [name, value] in Iterator(kStrings))
> let ([n, v] = [name, value])
> gStr.__defineGetter__(n, function() gStr._getStr(n, v));
Awesome work. Thanks, Mardak. Can you call Components.utils.forceGC() from here? Does it make the bug reproduce more reliably?
Assignee | ||
Comment 92•15 years ago
|
||
(In reply to comment #91) > Awesome work. Thanks, Mardak. Can you call Components.utils.forceGC() from > here? Does it make the bug reproduce more reliably? Mardak says he can, but it does not. Also, the error mysteriously went away... It would be very helpful to know what the actual exception is that we're squelching here: > } catch (e) { > log(["Couldn't get string '", name, "' from property '", value, "'"]); Since we are looking at a bug inside the JS engine, the exception could be something completely unexpected and illuminating. Or not. The patch fingered in comment 68 contains some noise about cloned Block objects, and we definitely have one of those here (being accessed via JSOP_NAME). I am still in the dark and help is welcome.
Comment 93•15 years ago
|
||
(In reply to comment #92) > It would be very helpful to know what the actual exception is that we're > squelching here: > > log(["Couldn't get string '", name, "' from property '", value, "'"]); I was able to get the problem to trigger one time after modifying .app/../modules/DownloadUtils.jsm with "e" as part of the array. It was "value is undefined". I don't remember the line, but the only way it should be able to trigger is from value.map.
Assignee | ||
Comment 94•15 years ago
|
||
Excellent. That makes sense and fits with the earlier stuff. It rules out a lot of sheer nonsense.
It would be even more useful to capture this in gdb in a debug build, maybe by changing the script there to call any rarely-used native function and setting a breakpoint in that:
> } catch (e) {
>+ Components.utils.forceGC();
> log(["Couldn't get string '", name, "' from property '", value, "'"]);
Dying to get my hands on the output of js_DumpStackFrame(cx->fp) right around there, with follow-up js_DumpObject(obj) calls on various objects along cx->fp->scopeChain.
Comment 95•15 years ago
|
||
Here's the stack frame of the getter being called with the scope change object and the parent: JSStackFrame at 0xbfffcf10 <unnamed function at 0x174deba0 (JSFunction at 0x17586578)> file DownloadUtils.jsm line 109 pc = 0x1dc1bed4 current op: call slots: 0x1e234cec sp: 0x1e234cfc = slots + 4 0x1e234cec: <unnamed function at 0x174ea460 (JSFunction at 0x17586620)> 0x1e234cf0: <Object at 0x174de480> 0x1e234cf4: "timeFewSeconds" 0x1e234cf8: undefined argv: 0x1e234cec (argc: 0) this: <Object at 0x174de480> rval: undefined flags: rooted_argv scopeChain: (JSObject *) 0x174deb60 object 0x174deb60 class 0x43f420 Block properties: enumerate permanent shared "n": slot -1 enumerate permanent shared "v": slot -1 proto <Block object at 0x174e1ae0> parent <Block object at 0x174de640> private 0x0 slots: 3 (reserved) = 4 object 0x174de640 class 0x43f420 Block properties: enumerate permanent shared "name": slot -1 enumerate permanent shared "value": slot -1 proto <Block object at 0x174e1a80> parent <Call object at 0x174de4e0> private 0x0 slots: 3 (reserved) = 0
Comment 96•15 years ago
|
||
To clarify, I modified DownloadUtils.jsm to call forceGC on exception with a breakpoint at js_GC to get the frame/scope chain blocks. This seems to trigger the problem from time to time on my main profile: Cu = Components.utils; Cu.import("resource://gre/modules/DownloadUtils.jsm"); DU = DownloadUtils; DU.getTimeLeft(-1); Cu.forceGC(); DU.getTimeLeft(1);
Comment 97•15 years ago
|
||
Some notes: Besides the JS issue, this screen shot in windows shows the status line text as well as the blank download window. Not sure if the JS issue plays into the status line at the bottom at the browser which shows the file is an undefined type downloading. As in this case it is a podcast/MP3 file. Modifying the Remember download history perf doesn't affect the download window display either turning it off and on again.
Comment 98•15 years ago
|
||
I've reproduced this blank window 4 times in a row on a tryserver built rev 9428880490ce BH_20090817. I went to the twit.tv site and I've only tried to download MP3 podcasts with this build. I haven't closed the browser yet and its the only file type I tried to download with this build. I adjusted the perf. Between Save-Link As-> initiations, but it has not updated the download window screen with the 4 MP3 files I downloaded. I'm not sure what codebase the tryserver build is based off of though.
Comment 99•15 years ago
|
||
Tryserver build Note: The tryserver build might be based on the nightly code base as its labeled as 3.7a1pre and non of my Firefox add-ons work. Restarted Browser Followup Behavior: I did a browser restart, went back to the same web page. Right clicked Save Link As-> and all the download history came up in the download manager window. The screen status text changes to a timer as shown in this screen shot. Its shows all my downloads for this profile including those downloads I did on an older build in the same install folder. A few things to note: I installed the build, downloaded files over and over again, the browser window was blank. Second, did a restart, went back to exact same web page and tried to download the same files and the download manager history came back. I had Remember Download History off/on between downloads, but checked between a browser restart. The window shows history every time I try to download again. --Hope that clarifies more of the behavior we're seen, and hopefully the JS can get figured out.
Comment 100•15 years ago
|
||
gczeal (forces a GC on every allocation, etc) might help make this bug reproducible. But I'm not sure how to use it nowadays.
Comment 101•15 years ago
|
||
There's an --enable-gczeal option to configure.
Comment 102•15 years ago
|
||
I've got some STR that seems to always work for me on Minefield 0818: 1) create a new profile 2) restart minefield saving session 3) open error console and paste in Cu = Components.utils; Cu.import("resource://gre/modules/DownloadUtils.jsm"); DU = DownloadUtils; DU.getTimeLeft(-1); Cu.forceGC(); DU.getTimeLeft(1); (It should say "A few seconds remaining,1") 4) restart minefield saving session 5) open error console again and paste in the above This time it results in the error/warning. Not sure why it only triggers on the third time, but once it does, you can restart and do the error console thing again and it'll trigger again.
Comment 103•15 years ago
|
||
Could this be a bug in XDR?
Assignee | ||
Comment 104•15 years ago
|
||
> I've got some STR that seems to always work for me on Minefield 0818:
This reproduces for me in locally built tracemonkey tip on Mac. W00t, thanks Mardak!
Comment 105•15 years ago
|
||
Jason, since we looked at all the changesets, can't we just review the bug and patch that turned this into a bug and reverse engineer the problem?
Assignee | ||
Comment 106•15 years ago
|
||
Feel free.
Assignee | ||
Comment 107•15 years ago
|
||
Sorry, I was rude. What I mean to say is, I re-reviewed the patch that caused this regression and couldn't figure out what might have caused this. But of course more eyes on that code are welcome. Unfortunately this doesn't reproduce (reliably anyway) in gdb, so I'm printf-debugging. I just discovered that the JSScope being shared by this Block object, its proto, and presumably a bunch of other Block objects, is owned. It shouldn't be. Probably XDR; at least I sure hope so. (The long story: js_PutBlockObject is being called, and it sets the Block object up correctly, but during GC, js_TraceObject is calling js_ShrinkSlots which nulls out obj->dslots. At that point the Block object is wounded, and if I get through this alive, I'll add assertions to the engine to detect this situation. IIUC, the precise change that caused this regression was to stop allowing scopes to be both owned and shared. That was an intentional change; I just missed a spot where it happens!)
Comment 108•15 years ago
|
||
(In reply to comment #107) > Unfortunately this doesn't reproduce (reliably anyway) in gdb I'm not sure if this will help more, but if it doesn't fail for the second getter after the first forceGC, you can try other getters for other properties: Cu = Components.utils; Cu.import("resource://gre/modules/DownloadUtils.jsm"); DU = DownloadUtils; DU.getTimeLeft(-1); Cu.forceGC(); DU.getTimeLeft(1); Cu.forceGC(); DU.getTimeLeft(5); Cu.forceGC(); DU.convertTimeUnits(1); Cu.forceGC(); DU.convertByteUnits(1); Cu.forceGC(); DU.getDownloadStatus(1234567, 2345678900, 3456)
Assignee | ||
Comment 109•15 years ago
|
||
The probable fix. Writing a test for this now.
Assignee | ||
Comment 110•15 years ago
|
||
Comment on attachment 395342 [details] [diff] [review] v1 The test is in bug 505798. This patch fixes it.
Attachment #395342 -
Flags: review?(brendan)
Comment 111•15 years ago
|
||
(In reply to comment #84) > I've seen this on Mac laptop, so we shouldn't need to debug this on a Tegra. fwiw, I'm seeing this consistently on my mac using the FF3.5.2 release build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 Also, this is reproducing consistently for me running on OSX10.5.8, and was also last week when I was still running on OSX10.5.7. HTH John.
Comment 112•15 years ago
|
||
Comment on attachment 395342 [details] [diff] [review] v1 Whew. Thanks to everyone who helped nail this. /be
Attachment #395342 -
Flags: review?(brendan) → review+
Assignee | ||
Comment 113•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/addb1c7c8f77 If someone would like to confirm this in the next hourly/nightly, I'd be much obliged. Thanks again to everyone who helped.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Target Milestone: --- → mozilla1.9.3a1
Comment 114•15 years ago
|
||
Jason, thanks. Looks like its working in the latest hourly, but haven't seen it blank yet. Well keep our fingers crossed. :)
Comment 116•15 years ago
|
||
Still Blank....
Comment 117•15 years ago
|
||
(In reply to comment #116) > Still Blank.... On *what*? You comment is not at all helpful unless you give us a build ID that you see it being blank.
Comment 118•15 years ago
|
||
It's version 3.6a2pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090822 Namoroka/3.6a2pre (.NET CLR 3.5.30729) is this what you need...
Comment 119•15 years ago
|
||
This was fixed on the trunk. Your using a 1.9.2 branch build. BE, Jason - Which I'm assuming since this is 1.9.2 blocker and nominated? Will this get pushed on the branch? As it probably hasn't been yet.
Updated•15 years ago
|
Attachment #395342 -
Flags: approval1.9.2?
Updated•15 years ago
|
Attachment #395342 -
Flags: approval1.9.2?
Comment 120•15 years ago
|
||
Comment on attachment 395342 [details] [diff] [review] v1 Do not need approval for 1.9.2 because this bug is a blocker.
Comment 121•15 years ago
|
||
Waiting for a push to the 1.9.2 branch.
Updated•15 years ago
|
Keywords: checkin-needed
Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/996fdc702f21
Keywords: checkin-needed → fixed1.9.2
Comment 123•15 years ago
|
||
Still blank tonight.
Comment 124•15 years ago
|
||
(In reply to comment #123) > Still blank tonight. I was landed nine hours ago. Nightly builds have not been produced for it yet (wait at least another 12 hours).
Updated•15 years ago
|
status1.9.2:
--- → beta1-fixed
Keywords: fixed1.9.2
Comment 128•15 years ago
|
||
I am having problem with blank download box and no download. Problem appeared for a few weeks in early October. There was resolution for about a week - starting around the 15th or so - and now I can't download the .doc any longer. I can't even pull up the document to look at it, much less download to print. I can see and download .docx documents. Also, I have no trouble with acrobat, powerpoint, etc.
Comment 129•14 years ago
|
||
?? Still have this problem with 3.5.6, upgraded to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) download manager is still blank (white).
Comment 130•14 years ago
|
||
Patrik: This bug is fixed for Firefox 3.6, and it was introduced only in nightly "trunk" builds and 3.6 nightlies/betas. You should file a new bug, after first looking a bit for existing ones and trying support forums. /be
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [orange], [nv] → , [nv]
You need to log in
before you can comment on or make changes to this bug.
Description
•