publish to file:// goes on forever

VERIFIED FIXED in mozilla1.0.1

Status

SeaMonkey
Composer
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: Lasse Marøen, Assigned: Charles Manske)

Tracking

Trunk
mozilla1.0.1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: publish [adt2 rtm][fixed in trunk],custrtm-[verified-trunk])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

16 years ago
When a site is set up to publish to a local or a network drive the publish
dialog goes on for ever without succeding or a warning.

To reproduce:

1. Set up a site to publish to a local or a network drive, like
file://c:/inetpub/wwwroot
2. Create a page, and publish to that site

Actual results:

The publish dialog goes on for ever (well at least 10 minutes..)

Expected results:

Publish is successful, OR fails

Preferably it should succeed, but I'll file an RFE for that..
(Reporter)

Comment 1

16 years ago
Filed bug 142173 for publishing to file://

Comment 2

16 years ago
--> cmanske
Assignee: syd → cmanske

Comment 3

16 years ago
-->brade
Assignee: cmanske → brade
URL: file://

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta1
Summary: publish to file:// goes on for ever → publish to file:// goes on forever
Whiteboard: publish

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+
Whiteboard: publish → publish [adt2 rtm]
Target Milestone: --- → mozilla1.0

Comment 4

16 years ago
Charley--I need your help with this one.  The problem I am seeing is that the
saving (publishing) is completed before the progress dialog comes up.  Could you
check if the progress dialog not being up is causing the missed progress
notification?

On another note, publishing a small html file (no images) to a local file does
seem to have worked (my html was saved).
OS: Windows XP → All
Hardware: PC → All
(Assignee)

Comment 5

16 years ago
I agree that the file is actually published correctly.
I don't think publishing is finished before the progress dialog comes up (there
might be some lag in the dialog display, but StartPublishing() is called 
at the end of the progress dialog startup code, so it is the dialog has been 
created.)
What I see when I turn on the "show debug" flags is that when done, 
gEditorOutputProgressListener::onStateChange is called with aStatus =
STATE_STOP, but the STATE_IS_NETWORK is not set. We test for both bit flags to 
conclude that publishing is finished, thus it just sits in the progress 
monitoring dialog if we don't receive that notification.
I've seen this problem before with FTP publishing, though not reproduceably :-(

Comment 6

16 years ago
I believe the network flag is not to be set for local files.  Perhaps we need to
special case this?

Comment 7

16 years ago
*** Bug 142173 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Keywords: mozilla1.0.1

Updated

16 years ago
Whiteboard: publish [adt2 rtm] → publish [adt2 rtm],custrtm-
(Assignee)

Comment 8

16 years ago
I'll look into this.
Assignee: brade → cmanske
Status: ASSIGNED → NEW
(Assignee)

Comment 9

16 years ago
Created attachment 87561 [details] [diff] [review]
patch v1

Compensate for incomplete onStateChange messages with publishing to "file://"
destination

Comment 10

16 years ago
Comment on attachment 87561 [details] [diff] [review]
patch v1

r=brade but I would like to see these tiny changes:
 * combine the first 2 ifs in the first block
 * expand on comment in 2nd block to explain that it is to handle case of file
with images
 * consistent use of { for gPersistObj assignment (other places in patch put {
on new line by itself)
Attachment #87561 - Flags: review+
(Assignee)

Comment 11

16 years ago
Created attachment 87571 [details] [diff] [review]
patch v2

More comments to explain why we can't combine the 2 sections of the patch as 
suggested. Move the "{" in the gPersistObj creation.

Comment 12

16 years ago
Comment on attachment 87571 [details] [diff] [review]
patch v2

r=brade if you combine the first 2 ifs
Attachment #87571 - Flags: review+
(Assignee)

Comment 13

16 years ago
Created attachment 87577 [details] [diff] [review]
patch v3

Better consolidation of "if" clauses and location of comments
Attachment #87561 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #87571 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Whiteboard: publish [adt2 rtm],custrtm- → publish [adt2 rtm][FIX IN HAND][need sr=],custrtm-
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 14

16 years ago
Comment on attachment 87577 [details] [diff] [review]
patch v3

r=brade
Attachment #87577 - Flags: review+

Comment 15

16 years ago
Comment on attachment 87577 [details] [diff] [review]
patch v3

sr=alecf, but I want to see two bugs:
1) bug for necko support for writing to file:// urls
2) but for fixing this after that has been implemented, and make 2) dependent
on 1)
Attachment #87577 - Flags: superreview+
(Assignee)

Comment 16

16 years ago
Bugs filed as requested: bug 151867 to implement network fix and bug 151869 to
remove the publishing code here and in nsIWebBrowserPersist.
(Assignee)

Comment 17

16 years ago
checked into trunk

Verification tests:
1. Create a new page an insert an image or edit a page with an image. Save
the file locally before publishing.
2. Click on "Publish" button to launch publish dialog. 
3. Use "New" to create a new Site Settings profile. Name it something like 
"File Protocol test."
Fill in "Publishing address" with a  file://... URL to enter an existing location 
on a local or network drive (different location than the current file.)
4. Go to Publish Tab. Fill in filename
4a. Testing just HTML file: Uncheck the "Include images..." checkbox and click
Publish.
Result: You should see the 'Publishing' progress dialog and the HTML filename
should display in the file list with green check if file copying succeeded.
Status message in dialog should be "Publishing Completed" and "All files 
published"

4b. Testing with image:
4b.1 Use File | Recent Pages to lod the original file in another Composer window.
4b.2 Use Publish again, select the same Sitename you created before. 
4b.3 Check the "Include images..." checkbox to copy the image as well. 
Click Publish button.
Result: Both the image and HTML filenames should appear in the Progress dialog
list with green checks and same status messages as above.

Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: adt1.0.1
Resolution: --- → FIXED
Whiteboard: publish [adt2 rtm][FIX IN HAND][need sr=],custrtm- → publish [adt2 rtm][fixed in trunk],custrtm-

Comment 18

16 years ago
working great and as desired on trunk 0617. Thx for the lear steps to verify 
this one, Charlie!
Whiteboard: publish [adt2 rtm][fixed in trunk],custrtm- → publish [adt2 rtm][fixed in trunk],custrtm-[verified-trunk]

Comment 19

16 years ago
adding adt1.0.1+.  Please get drivers approval before checking into the branch.
Keywords: adt1.0.1 → adt1.0.1+
Comment on attachment 87577 [details] [diff] [review]
patch v3

Approval granted for 1.0 branch checkin; please remove the mozilla1.0.1+
keyword when this is fixed and add the fixed 1.0.1 keyword.
Attachment #87577 - Flags: approval+

Updated

16 years ago
Keywords: mozilla1.0.1 → mozilla1.0.1+
(Assignee)

Comment 21

16 years ago
checked into mozilla1.0.1 branch
Keywords: mozilla1.0.1+ → fixed1.0.1

Comment 22

16 years ago
verified in 7/28 branch build
Status: RESOLVED → VERIFIED
Keywords: verified1.0.1

Comment 23

16 years ago
removing fixed1.0.1
Keywords: fixed1.0.1
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.