155334 - Unable to save page as plain text format

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Chris Petersen]

Build: 2002-07-01-05
Platform: OS X 10.1.5
Expected Results: A new text file containing the page's content should be
created on my local drive
What I got: Save File dialog opens and progress indicator will endlessly cycle.
Basically, no file is actually created on drive.

Steps to reproduce:

1) Go to any site
2) Choose Save As from File menu
3) Specify name of file and locate to save it.Click Save.
4) Saving File dialog opens and progress indicator to cycle. Status area in
dialog remains: 0.0 bytes of ??? total (at 0.0 bytes/sec)
5) No text file is ever saved to drive.

Comment 1

[Winnie Lam]

07-02 build.

The key here is saving the file as plain text format.  The other two options,
HTML complete and HTML source only, work.

Comment 2

[Greg K.]

Confirmed using Chimera/20020701.

Comment 3

[Chris Petersen]

Though this bug still remains in the latest build, I can no longer cancel or
close the Save as dialog when attempting to save as plain text. I was able
complete this task on the July 2nd build but can't now on the 3rd build. Wonder
if this is somewhat related to the check in for
http://bugzilla.mozilla.org/show_bug.cgi?id=154913.

Comment 4

[saari (gone)]

->sdagley

Comment 5

[Simon Fraser [no longer active]]

For me the page does get saved, but the progress dialog problems remain.

Comment 6

[Simon Fraser [no longer active]]

Regression from the fix for bug 154277, I think.

Comment 7

[Simon Fraser [no longer active]]

So when saving in plain text format, the onStateChange just gets two notifications:

STATE_START
STATE_STOP

When saving a single HTML page, we get:

STATE_IS_NETWORK + STATE_IS_REQUEST + STATE_START
STATE_IS_NETWORK + STATE_IS_REQUEST + STATE_STOP

When saving HTML complete, we get:

STATE_IS_NETWORK + STATE_IS_REQUEST + STATE_START
STATE_IS_REQUEST + STATE_STOP
STATE_IS_REQUEST + STATE_START
STATE_IS_NETWORK + STATE_IS_REQUEST + STATE_STOP
(assuming 1 image).

So how are we supposed to know when the download is really finished?

Comment 8

[Simon Fraser [no longer active]]

For now I'm fixing it so that we look for the STATE_NETWORK bit on the first
notification, then match that up with the last one, so:

 nsDownloadListener::OnStateChange(nsIWebProgress *aWebProgress,  nsIRequest
*aRequest,  PRUint32 aStateFlags, 
                                     PRUint32 aStatus)
 {
+  if (!mGotFirstStateChange)
+  {
+    mNetworkTransfer = ((aStateFlags & STATE_IS_NETWORK) != 0);
+    mGotFirstStateChange = PR_TRUE;
+  }
+  
   // when the entire download finishes, stop the progress timer and clean up
   // the window and controller. We will get this even in the event of a cancel,
   // so this is the only place in the listener where we should kill the download.
-  if ((aStateFlags & STATE_STOP) && (aStateFlags & STATE_IS_NETWORK)) {
+  if ((aStateFlags & STATE_STOP) && (!mNetworkTransfer || (aStateFlags &
STATE_IS_NETWORK))) {
     [mController killDownloadTimer];
     [mController setDownloadProgress:nil];
   }

Taking bug.

Comment 9

[Simon Fraser [no longer active]]

Checked in the above patch (and detabbed the file).

Comment 10

[Chris Petersen]

Thanks, Simon.. Verified on the 2002-07-22-05 NB.

Comment 11

[Chris Petersen]

Regressed in the 7/24 NB (2002-07-24-05)

Comment 12

[sairuh (rarely reading bugmail)]

chris, could you be seeing bug 159170? for me the progress meter just keeps
animating when the d/l window remains open. the file, however, is still saved.

Comment 13

[Simon Fraser [no longer active]]

This is actually a slightly different issue, which is covered by bug 159170, so
re-resolving this one.

Comment 14

[Chris Petersen]

Yes, the document is getting saved but progress indicator continues to animate.
This bug is actually fixed. Marking verified.