Closed
Bug 190465
Opened 22 years ago
Closed 22 years ago
Download/Saving of files/pages is completely broken for installer builds with GRE
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ostgote, Assigned: ssu0262)
References
Details
(Keywords: dataloss, regression, smoketest)
Attachments
(1 file)
(deleted),
patch
|
sspitzer
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030123 Netscape6/6.2 (Mozilla)
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030123
Any new regression?
If I use the GRE-enabled installer builds (not the talkback zip) 2003012308 and
2003012315 under Win NT4 I can't save anything! In contrast If I use the
talkback enabled zips I _don’t_ have these problems.
Reproducible: Always
Steps to Reproduce:
0) uninstall any installer build (delete remaining files)
1) dl a new build (installer-sea) and install it
2) clean new profile.
3) save any file or page (which variant – open DL Manager, Progress dialog, or
nothing is irrelevant)
Actual Results:
page: nothing appears (no dialog), nothing saved
file (with left click): alert „%TEMP%\xxx.yyy could not be saved, because the
source file could not be read.“ appears, nothing saved
file (with save link target as): „Save As“ dialog appears, after OK nothing is saved
general: Tools->DL Manager can’t be opened
Expected Results:
file is saved, DL Manager can be opened
Perhaps regression to patches for bug 181374, bug 189301, or bug 188887?
Correction: The last mentioned bug above should be bug 188877.
I tested it now with newest 24th build (installer-sea) I got. Same result. Weird.
Build 2003012404
Keywords: dataloss,
regression
Oh, I see errors in the JS console.
open DL Manager:
Error: uncaught exception: [Exception... "Component returned failure code:
0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult:
"0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame ::
chrome://communicator/content/tasksOverlay.js :: toDownloadManager :: line 51"
data: no]
saving a web page:
Error: [Exception... "Component returned failure code: 0x8000ffff
(NS_ERROR_UNEXPECTED) [nsIDownload.init]" nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)" location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: foundHeaderInfo :: line
380" data: no]
Source File: chrome://communicator/content/contentAreaUtils.js
Line: 380
Comment 4•22 years ago
|
||
I am seeing the same thing in the latest build. DL Manager will not open. I am
running Windows XP Pro.
Comment 5•22 years ago
|
||
I have the same problem on Win98. Build ID 2003012315.
If I click on the Mozilla nightly exe for windows, it throbs for a bit and then
stops. If I right-click and select "Save as..." it gives me the save dialog but
does nothing when I click OK.
Comment 6•22 years ago
|
||
ccing some people who may know what's up with nsIWebBrowserPersist not working....
I suspect this is just a packaging issue, so to installer.
Assignee: law → dveditz
Status: UNCONFIRMED → NEW
Component: File Handling → Installer
Ever confirmed: true
QA Contact: petersen → bugzilla
Whiteboard: DUPEME
Updated•22 years ago
|
Component: Installer → File Handling
Comment 7•22 years ago
|
||
I wonder if the change to saveURI on the 8th is the cause.
Can the people with this problem delete compreg.dat and xpti.dat and see if the
problem goes away.
Hopefully we're not seeing another issue with stale interface info.
Comment 8•22 years ago
|
||
I just tried deleting compreg.dat and xpti.dat. It didn't work.
I'm running WinXP Pro and using 1.3.0.2003012404.
Comment 9•22 years ago
|
||
deleting files didn't do anything for me either, same build as john on WinXP Home
Comment 10•22 years ago
|
||
Oh, contentAreaUtils.js calls saveURI, and it doesn't appear to have been
updated to reflect the new parameters.
Look back at the JS console information, it looks like your first failure was
when it tried to get download manager service. The error means that
nsServiceManager::GetService failed or returned a null pointer. So now we have
to figure out why the service manager couldn't instantiate it.
Could you check in your compreg.dat file and see if you have entry like:
@mozilla.org/download-manager;1,{edb0490e-1dd1-11b2-83b8-dbf8d85906a6}
Comment 11•22 years ago
|
||
*** Bug 190479 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
I have
@mozilla.org/download-manager;1,{edb0490e-1dd1-11b2-83b8-dbf8d85906a6}
in my compreg.dat file.
Comment 13•22 years ago
|
||
Works for me on a nightly build and contentAreaUtils.js was updated for my work:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=contentAreaUtils.js&root=/cvsroot&subdir=mozilla/xpfe/communicator/resources/content&command=DIFF_FRAMESET&rev1=1.72&rev2=1.73
Could it be some weird precompiled chrome issue?
Comment 14•22 years ago
|
||
Is this a dup of Bug #190319, or is that a seperate issue?
Comment 15•22 years ago
|
||
Strange. WFM with 2003012404 / XP. Installed via the network stub installer.
I can download files and save pages without any problem. Obviously, there's
some other factor involved than just the build and OS.
Comment 16•22 years ago
|
||
*** Bug 190491 has been marked as a duplicate of this bug. ***
Comment 17•22 years ago
|
||
Would turning off fastload possibly get around the precompiled issue if that's
the problem? It's easy enough to try if any of the people experiencing it could
try it.
Comment 18•22 years ago
|
||
I don't use fastload, but still have the problem.
Comment 19•22 years ago
|
||
Another thing to try - switch themes and then back again. I'm half convinced
this is some kind of chrome issue - you're picking up an old copy of comm.jar
from somewhere.
Comment 20•22 years ago
|
||
I switched from modern to classic, and then from classic to modern, still got
the same error I reported in Bug #190479
Comment 21•22 years ago
|
||
I use Pinball. I changed to Classic, exited, restarted, changed back to
Pinball, exited, restarted, and still broke.
Comment 22•22 years ago
|
||
->Sean, more fallout from the GRE install rearranging.
Assignee: dveditz → ssu
Comment 23•22 years ago
|
||
Upgrading to smoketest blocker since this blocks a smoketest blocker.
Severity: critical → blocker
Keywords: smoketest
Assignee | ||
Comment 24•22 years ago
|
||
I've seen this happen before on my system, but I can't reproduce it anymore.
Granted, I've been uninstalling and reinstalling several times a day and do
clean up my machine all the time to make sure there aren't any obsolete files.
I know ostgote@gmx.net mentioned that he uninstalled and deleted any remain
files, but I wonder if this could still be caused by bug 190144 somehow.
Is there anyone on campus that can reproduce this bug consistently? I'd like to
take a look at the machine.
Status: NEW → ASSIGNED
Comment 25•22 years ago
|
||
is this a dup of the other blocker? (see bug #190319)
Comment 26•22 years ago
|
||
I can reproduce on my machines - XP and 2k
Assignee | ||
Comment 27•22 years ago
|
||
It might be a dupe of bug 190319.
Seth, I'll help investigate this too. I'm finally able to reproduce it as well.
Assignee | ||
Comment 28•22 years ago
|
||
This does not look like a problem stemming from the GRE installer rearranging
patch because I've done the following to put GRE back into the netscape folder
(to test this problem):
* copied all of the GRE files back into the Netscape folder
* removed the GRE references from the windows registry
* renamed the GRE directory out of the way
* started up Netscape
Netscape starts up fine (if it didn't then it would mean that it couldn't find
GRE), but the Save As problem is still there.
Assignee | ||
Comment 29•22 years ago
|
||
Another possibility is that since the packaging files were changed, perhaps some
files are missing?
looking into this...
Comment 30•22 years ago
|
||
I see errors in my js console, too:
Error: [Exception... "Component returned failure code: 0x8000ffff
(NS_ERROR_UNEXPECTED) [nsIDownload.init]" nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)" location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: foundHeaderInfo :: line
376" data: no]
Source File: chrome://communicator/content/contentAreaUtils.js
Line: 376
(as others have reported)
Comment 31•22 years ago
|
||
Worksforme with 2003012304, Seamonkey installer build, Windows 98. Maybe
something happened between 2003012304 and 2003012315?
Flags: blocking1.3b-
Comment 32•22 years ago
|
||
it looks like part of the problem is we are missing downloadmanager.xpt
Comment 33•22 years ago
|
||
something is missing from the components dir
I can copy stuff from the .zip components dir, and if I remove the compreg.dat
(from my broken install) things start working.
narrowing it down...
Comment 34•22 years ago
|
||
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3b) Gecko/20030124
Still broken.
Comment 35•22 years ago
|
||
*** Bug 190319 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 36•22 years ago
|
||
appearently the code that loades the components load dlls just fine from
anywhere. However, .js files seem to need to be in the GRE's component dir.
Essentially just nsDownloadProgressListener.js needs to be installed, but I'm
uncommenting the other two .js files in case other parts of the download
manager are broken because of this.
Attachment #112568 -
Flags: superreview?(sspitzer)
Comment 37•22 years ago
|
||
Comment on attachment 112568 [details] [diff] [review]
patch v1.0
sr=sspitzer
let's log a spin off bug (maybe on dougt?) about this issue
our guess is that this .js could have lived in mozilla components dir, not the
GRE component dir, but that didn't work.
Attachment #112568 -
Flags: superreview?(sspitzer) → superreview+
Comment 38•22 years ago
|
||
local components work fine for me. if this isn't the case, we must stop ship on
1.3b for this major regression.
Comment 39•22 years ago
|
||
doug, we can't why it matters for the one .js component, but the others can
live in the mozilla component dir.
ssu will spin up a bug.
luckily, we have one component (the cause of this bug) to use to figure it out.
Assignee | ||
Comment 40•22 years ago
|
||
bug 190560 filed against the component loading problem.
Comment 41•22 years ago
|
||
Not sure why xah thinks this wouldn't block 1.3b. Renominating since that
determination is for drivers@mozilla.org
Flags: blocking1.3b- → blocking1.3b?
Comment 42•22 years ago
|
||
Comment on attachment 112568 [details] [diff] [review]
patch v1.0
shouldn't there be a corresponding removal or commenting out of these
components from the Mozilla package list?
Comment 43•22 years ago
|
||
That was a mistake, sorry. I agree that this should block 1.3b.
Updated•22 years ago
|
Flags: blocking1.3b? → blocking1.3b+
Comment 44•22 years ago
|
||
FYI, I can now download files with the 2003012417-TRUNK build. Thanks for the fix.
WFM (Resolved?).
Comment 45•22 years ago
|
||
*** Bug 190616 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 46•22 years ago
|
||
dveditz, no because they were not being packaged at all. I think in my first
pass on getting GRE working I missed that these 3 files were commented out here,
so I took them out of the mozilla packages inadvertently.
Once bug 190560 is fixed, these three files should probably be moved out of the
GRE packages and over to the mozilla packages.
closing this bug as fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 47•22 years ago
|
||
works fine with build 2003012417... but it is not working with 2003012508
Reporter | ||
Comment 48•22 years ago
|
||
WFM build 2003012508-trunk (installer-sea) on Win NT4
Thanks!
Comment 49•22 years ago
|
||
verified fixed with windows commercial trunk build 2003-01-27-09-trunk
Status: RESOLVED → VERIFIED
Comment 50•22 years ago
|
||
moving nsProgressDialog.js nsHelperAppDlg.js nsDownloadProgressListener.js into
the GRE component directory was the *wrong* thing to do. Please back out this
change.
Comment 51•22 years ago
|
||
> moving nsProgressDialog.js nsHelperAppDlg.js nsDownloadProgressListener.js into
> the GRE component directory was the *wrong* thing to do. Please back out this
> change.
ssu has a fix to move these files back. see bug #191048
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•