Closed Bug 76943 Opened 24 years ago Closed 24 years ago

No progress info during XPInstall

Categories

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

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: jimmykenlee, Assigned: slogan)

References

Details

(Keywords: regression, Whiteboard: [smartupdate])

Attachments

(1 file)

Patch that fixes this
751 bytes, patch
Details | Diff | Splinter Review
Build: 2001-04-19-22-trunk(WIN), 2001-04-19-08-trunk(MAC), 2001-04-19-21-trunk(LINUX) 1. Use 56K modem OR Launch browser, choose Preferences from Edit menu, click Advanced category, click Proxies, click Manual proxy configuration, from FTP Proxy field enter 'chainsaw.mcom.com' without the quotes, change Port from 0 to 8056, save changes, relaunch browser 2. Open update.html (ie. ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-04-19-22-trunk/u pdate.html) 3. Click Launch XPInstall button to upgrade RESULT: Download dialog appears. No progress meter. No text in the fields. Checking the temp directory does show the packages being downloaded. Eventually, the install does complete. EXPECTED RESULT: Progress meter grows as the download proceeds. Status text appears in the fields of the download dialog. NOTE: I tried the same update except changing ftp://sweetlou to http://jimbob since I have a similar set up. I found that the progress meter does appear from the Download dialog.
Nominating for Beta. We really need to have this in to inform users that a download is taking place. Users will encounter this UI or lack of UI when attempting to Smartupdate from 6.5 to any future release.
Keywords: nsbeta1
On a T1 connection there is woefully too little UI telling me what happens when the XPIs are being dloaded; I couldn't tell if we were hung or not. Also, is the throbber supposed to do anything? If not, maybe we should turf it since the throbber no moving could send the wrong signal to users that the operation is hung or complete when in fact it is not. Once the XPIs got dloaded things were nicer. I will try this over a 56k modem later to see how it performs there. Note to myself -- XUL needs some loving to make it non-resizable or fix the springs, vertical resizes are fugly.
The Download dialog should display a growing progress meter as packages are being downloaded, so the user knows that something is happening. After all packages are downloaded, then installation begins and the "barber pole" meter appears displaying the current package and file being installed. You can always run 6.0 to compare some of the UI. Hope this helps.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Keywords: regression
Whiteboard: [smartupdate]
This bug makes the product appear hung when getting the Java download as prompted by the plugin, and will also affect upgrades on the SmartUpdate site. Users on dialup modems will probably think the download is hung and give up.
Target Milestone: mozilla0.9.2 → mozilla0.9.1
will look at this come Monday
Status: NEW → ASSIGNED
Adding Jeremy Loeb to list. Syd, per your last comment, is this something you're working on then? This was a comment from Don Bragg via email: "Uh, I can't volunteer to fix this. If you want me to fix it you'll have to negotiate with my new manager." -Don
Adding Syd to list.
The following stack clearly shows we are getting progress callback invoked from necko, we are finding the progressmeter XUL in our document, that we are setting its value attribute. Now, why is the UI not updating? That is a question for David Hyatt perhaps, so I am cc'ing him. #0 nsXBLBinding::AttributeChanged (this=0x8944a88, aAttribute=0x8182b88, aNameSpaceID=0, aRemoveFlag=0) at nsXBLBinding.cpp:1348 #1 0x411c6e70 in nsXULElement::SetAttribute (this=0x8960be0, aNodeInfo=0x876c258, aValue=@0xbffff14c, aNotify=1) at nsXULElement.cpp:3019 #2 0x411c1242 in nsXULElement::SetAttribute (this=0x8960be0, aName=@0xbffff06c, aValue=@0xbffff14c) at nsXULElement.cpp:1408 #3 0x421d0e54 in nsInstallProgressDialog::setDlgAttribute (this=0x88b90f0, id=0x421f9296 "dialog.progress", name=0x421f9256 "value", value=@0xbffff14c) at nsInstallProgressDialog.cpp:291 #4 0x421d0ad9 in nsInstallProgressDialog::SetProgress (this=0x88b90f0, aValue=411048, aMax=722044, mode=110 'n') at nsInstallProgressDialog.cpp:244 #5 0x40144fe5 in XPTC_InvokeByIndex (that=0x88b90f4, methodIndex=8, paramCount=3, params=0x89be7d0) at xptcinvoke_unixish_x86.cpp:138 #6 0x401293a0 in EventHandler (self=0x8934bb8) at nsProxyEvent.cpp:506 #7 0x40129196 in nsProxyObject::Post (this=0x890c510, methodIndex=8, methodInfo=0x874156c, params=0xbffff358, interfaceInfo=0x80cbc28) at nsProxyEvent.cpp:449 #8 0x4012b971 in nsProxyEventObject::CallMethod (this=0x88f5d78, methodIndex=8, info=0x874156c, params=0xbffff358) at nsProxyEventObject.cpp:463 #9 0x4014554d in PrepareAndDispatch (self=0x88f5d78, methodIndex=8, args=0xbffff410) at xptcstubs_unixish_x86.cpp:80 #10 0x401457aa in nsXPTCStubBase::Stub8 (this=0x88f5d78) at ../../../../../../dist/include/xptcstubsdef.inc:10 #11 0x421d4cca in nsXPInstallManager::OnProgress (this=0x891fa88, request=0x8962548, ctxt=0x0, aProgress=411048, aProgressMax=722044) at nsXPInstallManager.cpp:829 #12 0x4216748e in ?? () from /opt/raptor/mozilla/dist/bin/components/libnecko2.so #13 0x42168263 in ?? () from /opt/raptor/mozilla/dist/bin/components/libnecko2.so #14 0x40144fe5 in XPTC_InvokeByIndex (that=0x8140f6c, methodIndex=3, paramCount=4, params=0x89448e8) at xptcinvoke_unixish_x86.cpp:138 #15 0x401293a0 in EventHandler (self=0x89448b8) at nsProxyEvent.cpp:506 #16 0x4012131b in PL_HandleEvent (self=0x89448b8) at plevent.c:590 #17 0x4012112c in PL_ProcessPendingEvents (self=0x80b4de8) at plevent.c:520 #18 0x401233ac in nsEventQueueImpl::ProcessPendingEvents (this=0x80b4dc0) at nsEventQueue.cpp:374 #19 0x409342e4 in ?? () from /opt/raptor/mozilla/dist/bin/components/libwidget_gtk.so #20 0x40933ecf in ?? () from /opt/raptor/mozilla/dist/bin/components/libwidget_gtk.so #21 0x40466aca in ?? () from /usr/lib/libglib-1.2.so.0 #22 0x40468186 in ?? () from /usr/lib/libglib-1.2.so.0
Gagan, the key difference here is that we must go through a proxy or over a modem in order to duplicate this problem. Any idea if or how slow(er) connections would interfere with ability to change XUL attributes?
I don't know enough about XUL to claim the right answer but my guess is that the XUL attributes are being updated thru an event which may get "clogged" on a slower connection. cc'ing darin though hyatt may best know more about how XUL attributes are updated.
> The Download dialog should display a growing progress meter as packages are > being downloaded, so the user knows that something is happening. After all > packages are downloaded, then installation begins and the "barber pole" meter > appears ... I was looking at this today over the internal LAN, and I didn't see the progress meter update as packages were download until the very end (although text did update). I did see the barber pole after that. Is it really clear that this is dependent on bandwidth (maybe I just don't know what I'm supposed to see, but I was getting very little feedback on a high-speed connection).
Calling FlushPendingNotifications() on the document after each attribute change does not help.
Confirmed (with printfs) that we call setAttribute() but the ProgressMeter frame AttributeChanged() method is never invoked (unless I am in a debugger and click next sufficiently slow). There is some seemingly temporal aspect to this bug, but I have no idea what that is.
After further investigation, I am convinced that this problem is not specific to slow connections. Sometimes it works as expected, but it clearly fails more often than succeeds. Changing Summary to exclude comment about slow connection. I observe similar behavior to John's experience.
Summary: No progress info running update.html on slow connection → No progress info running update.html
I concur, doesn't work over a t1 connection either.
This isn't us. Here are some stack snippets (in time order after the setAttribute call was made) that show some of the places AttributeChanged is invoked. But regardless of what my xul is -- text, progressmeter -- the XUL element-specific AttributeChanged function is not invoked. Passing to hyatt because he his prolly able to figure this out faster than I can. syd nsXBLBinding::AttributeChanged(nsXBLBinding * const 0x0495d690, nsIAtom * 0x0132c060, int 0, int 0) line 1344 nsXBLBinding::AttributeChanged(nsXBLBinding * const 0x0495d630, nsIAtom * 0x0132c060, int 0, int 0) line 1343 + 38 bytes nsGenericHTMLElement::SetAttribute(nsGenericHTMLElement * const 0x04958fb0, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 1443 nsGenericHTMLElement::SetFormControlAttribute(nsIForm * 0x00000000, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 3898 + 28 bytes nsGenericHTMLLeafFormElement::SetAttribute(nsGenericHTMLLeafFormElement * const 0x04958fb0, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 4090 nsXBLPrototypeBinding::AttributeChanged(nsXBLPrototypeBinding * const 0x04767500, nsIAtom * 0x0132c060, int 0, int 0, nsIContent * 0x0456cd20, nsIContent * 0x04951de0) line 670 nsXBLBinding::AttributeChanged(nsXBLBinding * const 0x049500b0, nsIAtom * 0x0132c060, int 0, int 0) line 1348 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd20, nsINodeInfo * 0x0444df20, const nsAString & {...}, int 1) line 3021 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd24, const nsAString & {...}, const nsAString & {...}) line 1408 + 31 bytes nsInstallProgressDialog::setDlgAttribute(const char * 0x05969ab8, const char * 0x05969ab0, const nsAString & {...}) line 291 + 53 bytes nsInstallProgressDialog::SetActionText(nsInstallProgressDialog * const 0x04579864, const unsigned short * 0x049e2630) line 215 + 25 bytes XPTC_InvokeByIndex(nsISupports * 0x04579864, unsigned int 7, unsigned int 1, nsXPTCVariant * 0x049e14a0) line 139 EventHandler(PLEvent * 0x049e5950) line 509 + 41 bytes nsProxyObject::Post(unsigned int 7, nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750, nsIInterfaceInfo * 0x00ac9ce0) line 449 + 9 bytes nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x04579d00, unsigned short 7, const nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750) line 463 + 52 bytes PrepareAndDispatch(nsXPTCStubBase * 0x04579d00, unsigned int 7, unsigned int * 0x006df800, unsigned int * 0x006df7f0) line 100 + 31 bytes SharedStub() line 124 nsXPInstallManager::OnStatus(nsXPInstallManager * const 0x057e2318, nsIRequest * 0x049e5540, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x006df880) line 849 + 36 bytes nsFTPChannel::OnStatus(nsFTPChannel * const 0x049e5548, nsIRequest * 0x00000000, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x00000000) line 430 + 113 bytes DataRequestForwarder::OnStatus(DataRequestForwarder * const 0x049e38dc, nsIRequest * 0x049e1550, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x049e1030) line 224 XPTC_InvokeByIndex(nsISupports * 0x049e38dc, unsigned int 4, unsigned int 4, nsXPTCVariant * 0x049e2920) line 139 EventHandler(PLEvent * 0x049e5820) line 509 + 41 bytes PL_HandleEvent(PLEvent * 0x049e5820) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x012628d0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000004c8, unsigned int 54380, unsigned int 0, long 19278032) line 1071 + 9 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 006d8a1a() 00058f64() PresShell::AttributeChanged(PresShell * const 0x045634d8, nsIDocument * 0x04559c60, nsIContent * 0x04958fb0, int 0, nsIAtom * 0x0132c060, int -1) line 4814 nsXULDocument::AttributeChanged(nsXULDocument * const 0x04559c60, nsIContent * 0x04958fb0, int 0, nsIAtom * 0x0132c060, int -1) line 1621 nsGenericHTMLElement::SetAttribute(nsGenericHTMLElement * const 0x04958fb0, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 1473 nsGenericHTMLElement::SetFormControlAttribute(nsIForm * 0x00000000, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 3898 + 28 bytes nsGenericHTMLLeafFormElement::SetAttribute(nsGenericHTMLLeafFormElement * const 0x04958fb0, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 4090 nsXBLPrototypeBinding::AttributeChanged(nsXBLPrototypeBinding * const 0x04767500, nsIAtom * 0x0132c060, int 0, int 0, nsIContent * 0x0456cd20, nsIContent * 0x04951de0) line 670 nsXBLBinding::AttributeChanged(nsXBLBinding * const 0x049500b0, nsIAtom * 0x0132c060, int 0, int 0) line 1348 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd20, nsINodeInfo * 0x0444df20, const nsAString & {...}, int 1) line 3021 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd24, const nsAString & {...}, const nsAString & {...}) line 1408 + 31 bytes nsInstallProgressDialog::setDlgAttribute(const char * 0x05969ab8, const char * 0x05969ab0, const nsAString & {...}) line 291 + 53 bytes nsInstallProgressDialog::SetActionText(nsInstallProgressDialog * const 0x04579864, const unsigned short * 0x049e2630) line 215 + 25 bytes XPTC_InvokeByIndex(nsISupports * 0x04579864, unsigned int 7, unsigned int 1, nsXPTCVariant * 0x049e14a0) line 139 EventHandler(PLEvent * 0x049e5950) line 509 + 41 bytes nsProxyObject::Post(unsigned int 7, nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750, nsIInterfaceInfo * 0x00ac9ce0) line 449 + 9 bytes nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x04579d00, unsigned short 7, const nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750) line 463 + 52 bytes PrepareAndDispatch(nsXPTCStubBase * 0x04579d00, unsigned int 7, unsigned int * 0x006df800, unsigned int * 0x006df7f0) line 100 + 31 bytes SharedStub() line 124 nsXPInstallManager::OnStatus(nsXPInstallManager * const 0x057e2318, nsIRequest * 0x049e5540, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x006df880) line 849 + 36 bytes nsFTPChannel::OnStatus(nsFTPChannel * const 0x049e5548, nsIRequest * 0x00000000, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x00000000) line 430 + 113 bytes DataRequestForwarder::OnStatus(DataRequestForwarder * const 0x049e38dc, nsIRequest * 0x049e1550, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x049e1030) line 224 XPTC_InvokeByIndex(nsISupports * 0x049e38dc, unsigned int 4, unsigned int 4, nsXPTCVariant * 0x049e2920) line 139 EventHandler(PLEvent * 0x049e5820) line 509 + 41 bytes PL_HandleEvent(PLEvent * 0x049e5820) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x012628d0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000004c8, unsigned int 54380, unsigned int 0, long 19278032) line 1071 + 9 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 006d8a1a() 00058f64() nsGfxScrollFrameInner::AttributeChanged(nsGfxScrollFrameInner * const 0x04915b70, nsIDocument * 0x04559c60, nsIContent * 0x04958fb0, int 0, nsIAtom * 0x0132c060, int -1) line 863 nsXULDocument::AttributeChanged(nsXULDocument * const 0x04559c60, nsIContent * 0x04958fb0, int 0, nsIAtom * 0x0132c060, int -1) line 1621 nsGenericHTMLElement::SetAttribute(nsGenericHTMLElement * const 0x04958fb0, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 1473 nsGenericHTMLElement::SetFormControlAttribute(nsIForm * 0x00000000, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 3898 + 28 bytes nsGenericHTMLLeafFormElement::SetAttribute(nsGenericHTMLLeafFormElement * const 0x04958fb0, int 0, nsIAtom * 0x0132c060, const nsAString & {...}, int 1) line 4090 nsXBLPrototypeBinding::AttributeChanged(nsXBLPrototypeBinding * const 0x04767500, nsIAtom * 0x0132c060, int 0, int 0, nsIContent * 0x0456cd20, nsIContent * 0x04951de0) line 670 nsXBLBinding::AttributeChanged(nsXBLBinding * const 0x049500b0, nsIAtom * 0x0132c060, int 0, int 0) line 1348 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd20, nsINodeInfo * 0x0444df20, const nsAString & {...}, int 1) line 3021 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd24, const nsAString & {...}, const nsAString & {...}) line 1408 + 31 bytes nsInstallProgressDialog::setDlgAttribute(const char * 0x05969ab8, const char * 0x05969ab0, const nsAString & {...}) line 291 + 53 bytes nsInstallProgressDialog::SetActionText(nsInstallProgressDialog * const 0x04579864, const unsigned short * 0x049e2630) line 215 + 25 bytes XPTC_InvokeByIndex(nsISupports * 0x04579864, unsigned int 7, unsigned int 1, nsXPTCVariant * 0x049e14a0) line 139 EventHandler(PLEvent * 0x049e5950) line 509 + 41 bytes nsProxyObject::Post(unsigned int 7, nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750, nsIInterfaceInfo * 0x00ac9ce0) line 449 + 9 bytes nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x04579d00, unsigned short 7, const nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750) line 463 + 52 bytes PrepareAndDispatch(nsXPTCStubBase * 0x04579d00, unsigned int 7, unsigned int * 0x006df800, unsigned int * 0x006df7f0) line 100 + 31 bytes SharedStub() line 124 nsXPInstallManager::OnStatus(nsXPInstallManager * const 0x057e2318, nsIRequest * 0x049e5540, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x006df880) line 849 + 36 bytes nsFTPChannel::OnStatus(nsFTPChannel * const 0x049e5548, nsIRequest * 0x00000000, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x00000000) line 430 + 113 bytes DataRequestForwarder::OnStatus(DataRequestForwarder * const 0x049e38dc, nsIRequest * 0x049e1550, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x049e1030) line 224 XPTC_InvokeByIndex(nsISupports * 0x049e38dc, unsigned int 4, unsigned int 4, nsXPTCVariant * 0x049e2920) line 139 EventHandler(PLEvent * 0x049e5820) line 509 + 41 bytes PL_HandleEvent(PLEvent * 0x049e5820) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x012628d0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000004c8, unsigned int 54380, unsigned int 0, long 19278032) line 1071 + 9 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 006d8a1a() 00058f64() nsBoxFrame::AttributeChanged(nsBoxFrame * const 0x036c8c70, nsIPresContext * 0x04567040, nsIContent * 0x0456cd20, int 0, nsIAtom * 0x0132c060, int 1) line 1203 nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const 0x04564b90, nsIPresContext * 0x04567040, nsIContent * 0x0456cd20, int 0, nsIAtom * 0x0132c060, int 1) line 9942 + 35 bytes StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x04564c50, nsIPresContext * 0x04567040, nsIContent * 0x0456cd20, int 0, nsIAtom * 0x0132c060, int -1) line 1290 PresShell::AttributeChanged(PresShell * const 0x045634d8, nsIDocument * 0x04559c60, nsIContent * 0x0456cd20, int 0, nsIAtom * 0x0132c060, int -1) line 4814 + 57 bytes nsXULDocument::AttributeChanged(nsXULDocument * const 0x04559c60, nsIContent * 0x0456cd20, int 0, nsIAtom * 0x0132c060, int -1) line 1621 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd20, nsINodeInfo * 0x0444df20, const nsAString & {...}, int 1) line 3056 nsXULElement::SetAttribute(nsXULElement * const 0x0456cd24, const nsAString & {...}, const nsAString & {...}) line 1408 + 31 bytes nsInstallProgressDialog::setDlgAttribute(const char * 0x05969ab8, const char * 0x05969ab0, const nsAString & {...}) line 291 + 53 bytes nsInstallProgressDialog::SetActionText(nsInstallProgressDialog * const 0x04579864, const unsigned short * 0x049e2630) line 215 + 25 bytes XPTC_InvokeByIndex(nsISupports * 0x04579864, unsigned int 7, unsigned int 1, nsXPTCVariant * 0x049e14a0) line 139 EventHandler(PLEvent * 0x049e5950) line 509 + 41 bytes nsProxyObject::Post(unsigned int 7, nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750, nsIInterfaceInfo * 0x00ac9ce0) line 449 + 9 bytes nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x04579d00, unsigned short 7, const nsXPTMethodInfo * 0x035fe1f4, nsXPTCMiniVariant * 0x006df750) line 463 + 52 bytes PrepareAndDispatch(nsXPTCStubBase * 0x04579d00, unsigned int 7, unsigned int * 0x006df800, unsigned int * 0x006df7f0) line 100 + 31 bytes SharedStub() line 124 nsXPInstallManager::OnStatus(nsXPInstallManager * const 0x057e2318, nsIRequest * 0x049e5540, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x006df880) line 849 + 36 bytes nsFTPChannel::OnStatus(nsFTPChannel * const 0x049e5548, nsIRequest * 0x00000000, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x00000000) line 430 + 113 bytes DataRequestForwarder::OnStatus(DataRequestForwarder * const 0x049e38dc, nsIRequest * 0x049e1550, nsISupports * 0x00000000, unsigned int 2152398854, const unsigned short * 0x049e1030) line 224 XPTC_InvokeByIndex(nsISupports * 0x049e38dc, unsigned int 4, unsigned int 4, nsXPTCVariant * 0x049e2920) line 139 EventHandler(PLEvent * 0x049e5820) line 509 + 41 bytes PL_HandleEvent(PLEvent * 0x049e5820) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x012628d0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000004c8, unsigned int 54380, unsigned int 0, long 19278032) line 1071 + 9 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 006d8a1a() 00058f64()
Assignee: syd → hyatt
Status: ASSIGNED → NEW
Not a duplicate of 79543. David, attinasi suggested that an optimization regarding dynamic changes to "value" attributes made a few months ago (sounds like when this bug was first seen) may be the cause of our problem. Can you give me details? Is there something I can change somewhere in XUL/XBL to see if this is causing the problem? Thanks, syd
Build 2001-03-20-06-Mtrunk(WIN) does not have a working progress meter. Build 2001-02-15-10-M0.8(WIN) does work.
I see the problem, damn. taking it back.
Assignee: hyatt → syd
No wonder the debugger was "fixing" it occasionally. There is code that only allows the progress bar to update after some interval has passed. This code was not letting us call down often enough, but if I did things slowly in the debugger we got updates (but still not enough). I pulled this code out (actually, just return TRUE now). UI update is nice and crisp. Will apply a patch.
Don't comment out, just delete -- cvs will remember. /be
r=ssu
heh, yeah, old habit from my days in embedded programming... with new silicon changing weekly, and no RCS in use, had to leave an audit trail somewhere. Will nuke los commentos.
I think the TimeToUpdate() function serves a purpose: it supposedly increases the speed of an install considerably. I don't have numbers though. Have you performance tested a large download like browser.xpi? Context switching to the UI thread each time we are notified by necko is expensive. Can we get download performance numbers with and without this fix for a large file like browser.xpi? Also note, TimeToUpdate() has multiple callers: the download progress callback, the install progress callback, the schedule-time progress update, and the finalize-time message update. Maybe just not calling the TimeToUpdate() function in the download callback is what you want to do for now. But leave a glaring "// XXX" comment in there and file a bug for tracking this so we can revisit this issue post beta if download performance is impacted. I'll be glad to review this once these issues have been addressed. Thanks!
I see no evidence that updating the progress meter causes a user perceptible degredation in download/install time. Surely in this case we are limited by network latency when downloading, or disk writes as we are unpacking and writing xpis. Updating the progress bar is probably just a small constant in the overall time equation.
bug filed for future investigation of presumed performance impact. I'll reference the bug in the XXX comment that I will add when checking in the fix.
Status: NEW → ASSIGNED
Reassigning to samir so he can investigate performance impact.
Assignee: syd → sgehani
Status: ASSIGNED → NEW
Download performance degradation: none observable (timing method: wall clock) Install performance degradation: only 20% (per install.log start/end times) Install progress is only part of the overall progress so if you normalize the degradation against overall progress this is a small price to pay. I think Syd's patch works great. Per bug 42548, this strategy to update 4 times a second only was employed to yield a 6x performance improvement. It appears that the underlying issue that caused bug 42548 has been fixed. Hence, I would venture to say it is safe remove the TimeToUpdate() call altogether. (Still doesn't solve the mystery of why this doesn't work with FTP but does with HTTP.) QA: please check Mac perf numbers once this is in. Thanks!
Assignee: sgehani → syd
r=sgehani
rs=mscott
a= asa@mozilla.org for checkin to 0.9.1
Fix checked in. woo hoo!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Build: 2001-05-30-06-trunk(WIN), 2001-05-30-11-trunk(MAC), 2001-05-30-08-trunk(LINUX) Very nice I say. Well done. Marking Verified!
Status: RESOLVED → VERIFIED
*** Bug 81425 has been marked as a duplicate of this bug. ***
Updating summary so dupes will find this more easily.
Summary: No progress info running update.html → No progress info during XPInstall
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: