User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316 The composer bug copy/pasting of relative links being converted to absolute links has been fixed, however the behavior still appears if the pasted document has not been saved. This is because Composer cannot determine the relative path for the pasted link. To prevent user confusion and addition bug reports, I propose a warning dialog be presented to the user warning them of the link conversion and suggesting then save the file fist, so relative linking can be determined. Reproducible: Always Steps to Reproduce: 1. edit page with relative links 2. select/copy object with a relative link 3. create a new page 4. paste object 5. examine link properties Actual Results: Link showed as absolute, not relative. Expected Results: recommend user save the file so a relative path could be determined and that an aboslute link was being used instead.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Here are my thoughts on this bug: 1) This is Composer-specific (it does not apply to "Midas" / rich text editing or to mail compose). 2) I think a dialog appearing on a paste action is very intrusive. I'd rather the software just did the right thing. 3) I believe the "right thing" for the software to do is to absolutize the link (so it is still accessible) and then relativize the link when the document actually is saved (if it can be made relative). 4) I'm pretty sure that the help system for Composer does tell the user to save their document before pasting. If not, I support having those changes made. 5) I would support a link checker that notified the user of absolute links prior to save/publishing actions. 6) I think this bug should be resolved as invalid or morphed into #4 and/or #5 above (but I defer to Daniel--if he wants this bug to remain open as is that is fine).
Assignee: composer → nobody
QA Contact: composer
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
I have confirmed the issue as described in the original ticket against SeaMonkey 1.1.16 Kathleen's #3 solution (auto-convert on save) is probably not a good idea because some people may be using hard links on purpose and not appreciate them being changed to relative. Kathleen's #5 (notification on save) is a good compromise, since the user is notified of the problem. If implemented, I would like to see it offer to automatically convert links to relative. IMHO the sooner the user is informed of the problem the better, so I don't see a problem notifying the user on the paste.
Please check in 2.0 Alpha 3 or a recent SeaMonkey "2.0b1pre" nightly. We are not actively developing SeaMonkey 1.x any further, only issuing security updates but no other changes. That said, Composer code shouldn't have changed a lot between 1.x and 2.0, so probably is still a valid bug/suggestion.
Rechecked against current trunk, looks like WFM, link pasted as relative, feel free to reopen if you still see the problem User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 Build identifier: 20120712003002
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.