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)
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)
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
I can't reproduce it, do I need to hit save as before the page finishes loading?
Reporter | ||
Comment 4•23 years ago
|
||
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?)
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.3
Assignee | ||
Comment 8•23 years ago
|
||
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
Assignee | ||
Comment 9•23 years ago
|
||
ccing darin in case he has any insight on webBrowserPersist as well.
Comment 10•23 years ago
|
||
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.
Assignee | ||
Comment 11•23 years ago
|
||
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?
Comment 12•23 years ago
|
||
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)).
Assignee | ||
Comment 13•23 years ago
|
||
man i feel stupid ;)
Assignee | ||
Updated•23 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•23 years ago
|
||
fixed, thanks adam.
Assignee | ||
Comment 16•23 years ago
|
||
*** Bug 154913 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•