Download/Saving of files/pages is completely broken for installer builds with GRE

VERIFIED FIXED

Status

Core Graveyard
File Handling
--
blocker
VERIFIED FIXED
15 years ago
a year ago

People

(Reporter: OstGote!, Assigned: Sean Su)

Tracking

({dataloss, regression, smoketest})

Trunk
x86
Windows NT
dataloss, regression, smoketest
Bug Flags:
blocking1.3b +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.50 KB, patch
(not reading, please use seth@sspitzer.org instead)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
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
(Reporter)

Comment 2

15 years ago
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
(Reporter)

Comment 3

15 years ago
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

15 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

15 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.
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

15 years ago
Component: Installer → File Handling

Comment 7

15 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

15 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.
deleting files didn't do anything for me either, same build as john on WinXP Home

Comment 10

15 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

15 years ago
*** Bug 190479 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
I have
@mozilla.org/download-manager;1,{edb0490e-1dd1-11b2-83b8-dbf8d85906a6}
in my compreg.dat file.

Comment 13

15 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

15 years ago
Is this a dup of Bug #190319, or is that a seperate issue?

Comment 15

15 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

15 years ago
*** Bug 190491 has been marked as a duplicate of this bug. ***

Comment 17

15 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

15 years ago
I don't use fastload, but still have the problem.

Comment 19

15 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

15 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

15 years ago
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
(Assignee)

Comment 24

15 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
is this a dup of the other blocker?  (see bug #190319)

Comment 26

15 years ago
I can reproduce on my machines - XP and 2k
(Assignee)

Comment 27

15 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

15 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

15 years ago
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)

Comment 31

15 years ago
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...

Comment 34

15 years ago
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3b) Gecko/20030124

Still broken.
Blocks: 189598
No longer blocks: 190319
*** Bug 190319 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 36

15 years ago
Created attachment 112568 [details] [diff] [review]
patch v1.0

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.
(Assignee)

Updated

15 years ago
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+

Comment 38

15 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.
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

15 years ago
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?

Comment 43

15 years ago
That was a mistake, sorry. I agree that this should block 1.3b.

Updated

15 years ago
Flags: blocking1.3b? → blocking1.3b+

Comment 44

15 years ago
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. ***
(Assignee)

Comment 46

15 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
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 47

15 years ago
works fine with build 2003012417... but it is not working with 2003012508
(Reporter)

Comment 48

15 years ago
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

Comment 50

15 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.
> 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.