239489 - add warning on relative links being forced to absolute links when pasted to new page

Status: RESOLVED WORKSFORME

(SeaMonkey :: Composer, enhancement)

Description

[Robert Eden]

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.

Comment 1

[Kathleen :Brade]

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).

Comment 2

[Robert Kaiser]

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

Comment 3

[Robert Eden]

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.

Comment 4

[Robert Kaiser]

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.

Comment 5

[Phoenix]

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