Closed Bug 154277 Opened 23 years ago Closed 23 years ago

Attempting to save page results in crash (@objc_msgSend)

Categories

(Camino Graveyard :: Page Layout, defect)

PowerPC
macOS
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED
Chimera0.3

People

(Reporter: chrispetersen, Assigned: mikepinkerton)

References

()

Details

(Keywords: crash)

Attachments

(2 files)

Build: 2002-06-25-05 Platform: OS X 10.1.5 Expected Results: Crash shouldn't occur after saving content What I got: Crash occurs Steps to reproduce: 1) Go to either url provided 2) Select Save As from File menu. Click Save button in the Save dialog. 3) Download dialog opens and closes, then application crashes. (note: this doesn't reproduce with other sites like www.macminute.com and www.ebay.com)
Severity: normal → blocker
Keywords: crash
Attached file Stack trace
I could reproduce with NB's going back to Jun 19 (2002-06-19-05). I do have a older build Jun 13th (2002-06-13-05) which I can't reproduce the crash. With June 13th build, the download window remains open after file is transfered and doesn't close like the current nightly's do.
I can't reproduce it, do I need to hit save as before the page finishes loading?
No , you can let the page load completely. Select Save As from File menu or Control-click to display Save Page as from contextual menu. You might want to delete your browser cache before you visit either site too. Then try saving the page again.
Confirmed using Chimera/20020625. My first test, at macnn.com, worked fine, but my second, at apple.com, failed as described, crashing also in objc_msgSend. (Shouldn't this be critical, not blocker?)
I still haven't had good luck with this yet
Assignee: saari → pinkerton
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.3
ok, here's what's going on. cc'ing adam in case he has any ideas: We create a progress listener (nsDownloadListener) and tie it to the webBrowserPersist. The act of saving webpages opens a couple httpChannels, all with the same progress listener. When the first one completes, our d/l listener says "ok, it's all done, i'm going to shut down the progress dialog", but then later another progress update comes in from a different http channel and pings the listener that thinks it's already done. It then tries to update status in the already deleted window, and booom. How do we know when the d/l is really done if all the channels use the same progress listener? Or should we be listening to something other than |aStateFlags & STATE_STOP| in OnStateChanged() to indicate a download is complete?
Blocks: 147975
ccing darin in case he has any insight on webBrowserPersist as well.
Are you testing for STATE_IS_NETWORK as well? That should indicate all network activity has finished. STATE_STOP just means that particular request has finished.
in OnStateChange(), if i do if (aStateFlags & (STATE_STOP | STATE_IS_NETWORK)) { // ... dl is done, kill window then i only get 2.3k of any download. changing this back to only check STATE_STOP makes it work. what am i doing wrong?
Testing for (StateFlags & (aSTATE_STOP | aSTATE_IS_NETWORK)) is going to succeed if either flag is present. You need to change the test to test for both combined, e.g. ((aStateFlags & STATE_STOP) && (aStateFlags & STATE_IS_NETWORK)).
man i feel stupid ;)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
fixed, thanks adam.
Verified in the 2002-06-28-05 NB.
Status: RESOLVED → VERIFIED
*** Bug 154913 has been marked as a duplicate of this bug. ***
No longer blocks: 147975
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: