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)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ostgote, Assigned: ssu0262)

References

Details

(Keywords: dataloss, regression, smoketest)

Attachments

(1 file)

patch v1.0
1.50 KB, 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?
Please test with a build from the 24th.
Whiteboard: DUPEME
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

I am seeing the same thing in the latest build. DL Manager will not open. I am
running Windows XP Pro.
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.
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
Component: Installer → File Handling
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.
I just tried deleting compreg.dat and xpti.dat. It didn't work.
I'm running WinXP Pro and using 1.3.0.2003012404.
deleting files didn't do anything for me either, same build as john on WinXP Home
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}
*** Bug 190479 has been marked as a duplicate of this bug. ***
I have
@mozilla.org/download-manager;1,{edb0490e-1dd1-11b2-83b8-dbf8d85906a6}
in my compreg.dat file.
Is this a dup of Bug #190319, or is that a seperate issue?
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.
*** Bug 190491 has been marked as a duplicate of this bug. ***
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.
I don't use fastload, but still have the problem.
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.
I switched from modern to classic, and then from classic to modern, still got
the same error I reported in Bug #190479
I use Pinball.  I changed to Classic, exited, restarted, changed back to
Pinball, exited, restarted, and still broke.
Blocks: 190319
->Sean, more fallout from the GRE install rearranging.
Assignee: dveditz → ssu
Upgrading to smoketest blocker since this blocks a smoketest blocker.
Severity: critical → blocker
Keywords: smoketest
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
is this a dup of the other blocker?  (see bug #190319)
I can reproduce on my machines - XP and 2k
It might be a dupe of bug 190319.

Seth, I'll help investigate this too.  I'm finally able to reproduce it as well.
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.
Another possibility is that since the packaging files were changed, perhaps some
files are missing?

looking into this...
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)
Worksforme with 2003012304, Seamonkey installer build, Windows 98. Maybe
something happened between 2003012304 and 2003012315?
Flags: blocking1.3b-
it looks like part of the problem is we are missing downloadmanager.xpt
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...
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3b) Gecko/20030124

Still broken.
Blocks: 189598
*** Bug 190319 has been marked as a duplicate of this bug. ***
Attached patch patch v1.0 — — Splinter Review 
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 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+
local components work fine for me.  if this isn't the case, we must stop ship on
1.3b for this major regression.
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.
bug 190560 filed against the component loading problem.
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 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?
That was a mistake, sorry. I agree that this should block 1.3b.
Flags: blocking1.3b? → blocking1.3b+
FYI, I can now download files with the 2003012417-TRUNK build. Thanks for the fix.

WFM (Resolved?).
*** Bug 190616 has been marked as a duplicate of this bug. ***
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
works fine with build 2003012417... but it is not working with 2003012508
WFM build 2003012508-trunk (installer-sea) on Win NT4

Thanks!
verified fixed with  windows commercial trunk build 2003-01-27-09-trunk
Status: RESOLVED → VERIFIED
moving nsProgressDialog.js nsHelperAppDlg.js nsDownloadProgressListener.js into
the GRE component directory was the *wrong* thing to do.  Please back out this
change.
> 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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: