Closed Bug 32956 Opened 20 years ago Closed 20 years ago

Triggering same xpi file in same session fails (mem cache on)

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P3, major)

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jimmykenlee, Assigned: davidm)

Details

(Whiteboard: 2d)

Build: 2000-03-22-06-M15-nb1b(WIN), 2000-03-22-05-M15-nb1b(MAC), 
2000-03-22-05-M15-nb1b(LINUX)

1. From http://jimbob/trigger2.html, click drop-down menu and select any
   test, a_adddelcomp and click Trigger button
2. Click OK from confirmation dialog to install
3. Repeat step #1 and trigger the same test

RESULT:
The Download dialog flashes quickly.  Checking the install.log reveals that the 
second trigger was not recorded.  Checking the installation shows that it did 
not occur.

EXPECTED RESULT:
Triggering the same archive withing the same session is possible.
Jimmy says that it just has to be in the same browser session, the triggers 
don't have to be back to back.
Stepping throug debugger, we found out when we trigger the same install xpi file 
twice or more, necko causes OnStartRequest to be called twice, and causing us to 
fail on the 2nd return, so onStopRequest gets called and the whole XPInstall is 
skipped.  Xpi file was never getting processed.  Turning cache off will prevent 
this problem to occur.

reassigning to davidm.

this is a regression, please help.    ~thanks.
Assignee: cathleen → davidm
Severity: normal → major
Target Milestone: --- → M16
Keywords: beta2
I thought Ruslan or Jud was looking at this problem. Cc'ing.
Whiteboard: 2d
I believe this is working now but I can't seem to find install.log. I saw some 
code which I think was designed to fix the double onStart issue.
Verified there is now only 1 start request. marking wfm
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
with today's tip debug build, we're still seeing OnStartRequest being called 
twice.  :-(

REOPENING...

David, do you have time to take a look at my tree?
reopening...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
You will find  nsXPInstallManager::OnStartRequest in 
mozilla/xpinstall/src/nsXPInstallManager.cpp -- you can set a breakpoint there. 
Don't rely on the Install.log data, with some recent nsFileSpec==>nsILocalFile 
changes about to be checked in the result is the file gets installed twice the 
second time (for a total of three installs) rather than skipped.
Summary: Triggering same xpi file in same session fails → Triggering same xpi file in same session fails (mem cache on)
Keywords: nsbeta2
I think what happened is that ruslan backed out a change which fixed this but 
broken some other things. I'll take another look at it when I get my build for 
today working.
Keywords: beta2
Is there Cancel() involved there somehow? As result of me backing off my changes 
from Friday - we're in square 1 (as before). I don't know if Warren's backed out 
his changes for killing OnStart from the event queue when the cancel occured.
warren has not backed that out
Ok. David, if your attempt to make sense of it is not successfull - reassign it 
to me. May be we should put asserts into listeners to complain about 
notifications being fired twice or out of order.
Are you saying it's time for me to back that out now? I wasn't sure of the 
ordering in which these things needed to occur.
No. Don't back it out. I was afraid that it was backed out.
ugh, when should it be backed out then?
When the webshell is fixed to stop crashing when it sees OnStart before 
OnHeadersAvailable
I meant to say "without following OnHeadersAvailable/OnDataAvailable"
OK heres the story as far as I can tell. We are doing an if modified request and 
the server is saying it is OK to use the cache date.
	a nsHTTPServerListener is created
	this nsHTTPServerListener::Abort is called when we realize the cache is OK
	however there is already an OnStartRequestEvent in existence which calls the 
xpinstall::OnStartRequest ( Is warrens code supposed to abort this?)

	Then the caches event fires and it also calls xpinstall and there is much 
weeping and gnashing of teeth.

I haven't figured out where the nsHTTPServerListener::OnStartRequest event is 
coming from yet but my thoughts are that either abort has to cancel outstanding 
events ( this could be hairy and potentially add some time dependant bugs) or 
the event should not be issued until after we finish checking if the cached data 
is usable. 
Is there a pref to turn off pipelining? Heres the http log of a failed attempt.

0[1a906a1c]: Creating nsHTTPChannel [this=1a56f21c] for URI: http://jimbob/jars/
a_addmacpatch.xpi.
0[1a906a1c]: Creating nsHTTPRequest [this=1a4ec0ac] for URI: http://jimbob/jars/
a_addmacpatch.xpi.
0[1a906a1c]: 	ParseStatusLine [this=1a624960].	HTTP-Version: HTTP/1.1
0[1a906a1c]: 	ParseStatusLine [this=1a624960].	Status-Code: 200
0[1a906a1c]: 	ParseStatusLine [this=1a624960].	Reason-Phrase: OK
0[1a906a1c]: Creating nsHTTPPipelinedRequest [this=1a524530], created=3, 
deleted=2
0[1a906a1c]: nsHTTPPipelinedRequest::AddToPipeline () [this=1a524530] count=1, 
longest pipeline=1
0[1a906a1c]: nsHTTPPipelinedRequest::WriteRequest ()[1a524530], mOnStopDone=1, 
mTransport=0
0[1a906a1c]: nsHTTPHandler::RequestTransport.	Got a socket transport for 
nsHTTPChannel [1a56f21c]. 1  Active transports.
0[1a906a1c]: 
nsHTTPRequest::Build() [this=1a524530].	Writing Request:
=== Start
GET /jars/a_addmacpatch.xpi HTTP/1.1
If-Modified-Since: Fri, 31 Mar 2000 01:03:26 GMT
If-None-Match: "63536-25b-38
0[1a906a1c]: nsHTTPRequest [this=1a524530]. Starting to write data to the 
server.
0[1a906a1c]: 
nsHTTPRequest::OnStopRequest () [this=1a524530], iStatus=0
0[1a906a1c]: nsHTTPRequest [this=1a524530]. Finished writing request to server.	
Status: 0
0[1a906a1c]: Creating nsHTTPResponseListener [this=1b777900] for URI: http://
jimbob/jars/a_addmacpatch.xpi.
0[1a906a1c]: Creating nsHTTPServerListener [this=1b777900].
0[1a906a1c]: nsHTTPPipelinedRequest::WriteRequest ()[1a524530], mOnStopDone=1, 
mTransport=1a871c94
0[1a906a1c]: nsHTTPServerListener::OnStartRequest [this=1b777900].
0[1a906a1c]: nsHTTPServerListener::OnDataAvailable [this=1b777900].
	stream=1b811010. 	offset=0. 	length=153.
0[1a906a1c]: nsHTTPServerListener::ParseStatusLine [this=1b777900].	aLength=153
0[1a906a1c]: 	ParseStatusLine [this=1b777900].	Got Status-Line:HTTP/1.0 304 
Use local copy

0[1a906a1c]: 	ParseStatusLine [this=1a627384].	HTTP-Version: HTTP/1.0
0[1a906a1c]: 	ParseStatusLine [this=1a627384].	Status-Code: 304
0[1a906a1c]: 	ParseStatusLine [this=1a627384].	Reason-Phrase: Use local copy
0[1a906a1c]: 	OnDataAvailable [this=1b777900]. Parsing Headers
0[1a906a1c]: 	ParseHTTPHeader [this=1b777900].	Got header string:Server: 
Netscape-Enterprise/3.6 

0[1a906a1c]: 	ParseHTTPHeader [this=1b777900].	Got header string:Link: <http:/
/jimbob.mcom.com/jars/a_addmacpatch.xpi?PageServices>; rel="PageServices"

0[1a906a1c]: 	ParseHTTPHeader [this=1b777900].	Got header string:

0[1a906a1c]: nsHTTPChannel::FinishedResponseHeaders [this=1a56f21c].
0[1a906a1c]: ProcessStatusCode [this=1a56f21c].	Status - Redirection: 304.
0[1a906a1c]: nsHTTPChannel::ProcessNotModifiedResponse [this=1a56f21c].	Using 
cache copy for: http://jimbob/jars/a_addmacpatch.xpi
0[1a906a1c]: nsHTTPServerListener::Abort [this=1b777900].
0[1a906a1c]: nsHTTPResponse::UpdateHeaders [this=1a624960].
0[1a906a1c]: 	UpdateHeaders [this=1a624960].	New response header: 'server: 
Netscape-Enterprise/3.6'
0[1a906a1c]: 	UpdateHeaders [this=1a624960].	New response header: 'link: <
http://jimbob.mcom.com/jars/a_addmacpatch.xpi?PageServices>; rel="PageServices"'
0[1a906a1c]: Creating nsHTTPResponseListener [this=1a65d128] for URI: http://
jimbob/jars/a_addmacpatch.xpi.
0[1a906a1c]: Creating nsHTTPCacheListener [this=1a65d128].
0[1a906a1c]: Deleting nsHTTPPipelinedRequest [this=1a524530], created=3, 
deleted=3
0[1a906a1c]: nsHTTPCacheListener::OnStartRequest [this=1a65d128]
0[1a906a1c]: nsHTTPCacheListener::OnStopRequest [this=1a65d128]
0[1a906a1c]: nsHTTPChannel::ResponseComplete () [this=1a56f21c]  mDataListenet=
1b69be0c, Status=20000040005
0[1a906a1c]: nsHTTPChannel::OnStopRequest(...) [this=1a56f21c].	OnStopRequest to 
consumer failed! Status:80070057
0[1a906a1c]: Deleting nsHTTPCacheListener [this=1a65d128].
0[1a906a1c]: nsHTTPServerListener::OnStopRequest [this=1b777900].	Status = 0, 
mDataReceived=1
0[1a906a1c]: nsHTTPChannel::ResponseComplete () [this=1a56f21c]  mDataListenet=
0, Status=0
0[1a906a1c]: nsHTTPHandler::ReleaseTransport [this=1aab4490] i_pTrans=1a871c94, 
aCapabilites=0, aKeepAliveTimeout=0, aKeepAliveMaxCon=-1, maxKeepAlives=0
0[1a906a1c]: nsHTTPHandler::ReleaseTransport.	Releasing socket transport 
1a871c94.
0[1a906a1c]: nsHTTPHandler::ReleaseTransport ():pendingChannels=0, InUseCount=0
0[1a906a1c]: Deleting nsHTTPServerListener [this=1b777900].
0[1a906a1c]: Deleting nsHTTPChannel [this=1a56f21c].
0[1a906a1c]: Deleting nsHTTPRequest [this=1a4ec0ac].
fix checked. Actually have bit of confidence in this one.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Build: 2000-04-25-09-M16(WIN), 2000-04-25-08-M16(MAC), 2000-04-25-12-M16(LINUX)

We can trigger back to back.  Marking Verified!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.