Composer requires a "Site Name" change when publsihing

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Composer
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: Jaime Rodriguez, Jr., Assigned: Charles Manske)

Tracking

Trunk
mozilla1.0
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT3]publish)

(Reporter)

Description

17 years ago
Build ID: 2002032803
Reproducible: Frequently

1. Launch N6
2. Select Edit Page from the File menu to edit a document
3. Edit your document
4. Click on the Publish button

Results: Recieve a request (error dialog) to change the SITE NAME.

Expected Behavior: If it is a site , that I have previously published to, I
should not be requested to change it, if I have published to the site
previously. Also, I should be able to select it from the Publish tab.
(Reporter)

Comment 1

17 years ago
Nominating for nsbeta1, and marking as ADT3. There is an existing workaround
(i.e. Name Site with a different name, and you will be able to Publish), but it
requires the user to name the same site several times. This is not that severe
because a savy user could work around the issue, but it should affect heavy
publishing users.
Keywords: 4xp, nsbeta1, nsdogfood
Whiteboard: [ADT3]

Comment 2

17 years ago
--> charley
Assignee: syd → cmanske
(Assignee)

Comment 3

17 years ago
I'm fairly sure this is a side effect of StripUsernamePassword not working 
correctly; we are stripping of the scheme and thus do not recognize the
url the second time we publish.
See bug 134248
Status: NEW → ASSIGNED
Depends on: 134248
Whiteboard: [ADT3] → [ADT3]publish
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

17 years ago
No longer depends on: 134248

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 4

17 years ago
This is fixed in my tree. Hopefully because of fix to 134248. But definitely 
with fixes to 5 other publishing bugs in my tree.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 5

17 years ago
Jaime, I am not exactly sure what you mean by "Recieve a request (error dialog)
to change the SITE NAME."  

If you mean that the site name is populated with the URL of the page, even
though you would expect that it be populated with the settings of the page. 
Then that issue will solve itself if you enter the url of the site in the "http
address to browse to:" field when originally publishing the page.  

If you mean that you are recieving and actual error dialog, than I am unable to
reproduce this problem so I would assume it is fixed.

I am marking VERIFIED, because it seems to me that this is all working as
designed.  

Jaime, if you are still able to reproduce this problem, please give more clear
steps to reproduce and reopen this bug.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 6

17 years ago
Sorry, to be clear, I receive an *error message* stating that the existing "Site
Name" is already in use, and that I have to type in another "Site name", even
though I am publishing the exact same document, with the same name, to the same
place.
(Assignee)

Comment 7

17 years ago
The case that Jaime discusses is fixed, but it might take waiting for all the 
related fixes I have in my tree are checked in. It's hard to prove one way or
another because of all the new fixes I have.

Comment 8

17 years ago
Jaime, I am not seeing the problem you described either.  

Please try a newer build (after 03-30)and reopen this bug if you are still
recieving the message.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.