173931 - Difficult to make relative links & links to anchors in another document

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[Rob W.W. Hooft]

The "Link Properties" dialog used to create a new link has a "choose file"
button, but if that button is used to select another file:

 * The file name will always be "absolute" and not "relative", such that the
document tree can no longer be moved. It is not possible to select a relative
path, because the widget for that function is greyed out.

 * The list of anchors still only contains all anchors in the current file, not
in the file chosen. This makes it annoyingly difficult to add a link to an
anchor in anothjer file.

Comment 1

[Kathleen :Brade]

-->cmanske

Comment 2

[Charles Manske]

Are you creating the link in a new, unsaved docuemnt? 
The link inserted from the "Choose" button will always be relative, but ONLY
if the page your editing is saved first. We can't figure out the relative link
if there's no base url!
As for the other problem about looking at anchors in another page, yes, that is 
annoying. I already have a bug on that.

Comment 3

[Rob W.W. Hooft]

Nope, it is an existing document, originally made using Netscape 4 composer. We
see that the text given for the link in the box is always absolute, and we're
always making it relative by hand, because the "Relative link" checkbox is
disabled. Are you saying that that is not what is inserted in the document, and
that we're changing the link to "../../fr591/usermanual.html" for nothing,
because that is done automatically just before the actual link is inserted in
the document? In that case a better bug description would be that the user
interface is confusing us...

Comment 4

[Charles Manske]

For an existing document, when you pick a file from "Choose" button or type 
a full url (including "file://...") the link should made relative automatically
AND display as such in the input field, and the checkbox should be checked.
The only thing that should cause failure to relativize is if page and link href
are on different drives. Please attach a sample file (reduce down to essential
parts) and example link urls and I will investigate. 
It seems to be working just fine in my current 1.2 mozilla trunk build (10/30/02)

Comment 5

[Mats Palmgren (inactive)]

I think the second part of the problem (rel. anchor list) is bug 61225

Comment 6

[timeless]

*** Bug 212174 has been marked as a duplicate of this bug. ***

Comment 7

[Alfonso Martinez]

*** Bug 225783 has been marked as a duplicate of this bug. ***

Comment 8

[Alfonso Martinez]

*** Bug 225312 has been marked as a duplicate of this bug. ***

Comment 9

[Ken Laster]

Bug 212174 has been deemed a duplicate of this bug. I find this unfortuntate
since the symptoms are somewhat different (although similar). The original
report is experienced with the setting of Background Images. I find it happening
on OS X, and is probably happening in all OS's not just XP, so this bug should
be revised for all OS's. It is a major problem and prohibits me from using
Composer therefore the severity should be revised to be Major or Critical
(IMHO). Please refer to Bug 212174 for a more accurate description of the Bug.

Comment 10

[Mike Cowperthwaite]

Rob Hooft, is this bug still an issue for you?  Have you followed the suggestion 
in comment 4?

Comment 11

[Rob W.W. Hooft]

(In reply to comment #10)
> Rob Hooft, is this bug still an issue for you?  Have you followed the suggestion 
> in comment 4?

The problem still occurs here with recent versions of Mozilla. It could be
caused by drive problems as suggested under #4, since the person that is
observing this is using a mapped SMB drive (H:) (for ALL documents). It is
essential that links are relative, as the files are finally uploaded to a web
server.

There is another strange effect though: if the document is "Save"d, the links
are absolute. If the document is "Save as.."d, the links are relative !?!?!?

Comment 12

[Mike Cowperthwaite]

For small test files, I am not seeing links created as absolutes unless the 
document being edited has not yet been saved, or if the linked document resides 
on a different drive than the edited document -- just as Charles Manske said it 
worked, 18 months ago.  There have been recent fixes for maintaining relativity 
in similar paths in the source (e.g. images) but links seem to have been working 
OK all along.

I do notice in 1.7 that the checkbox for "URL is relative to page location" is 
always disabled and unchecked when inserting a link, whether the link is being 
inserted into a saved or unsaved document; but in a saved document, when a link 
is preselected and the Insert Link dialog opened, that checkbox is initialized 
according to the actual text of the link, and toggling it also automatically 
adjusts the text.  (Note that the absolute links are always prefixed with
"file://", which is not very useful at all on a published web page.)

Compare this to the same checkbox when performing Insert Image, which enables as 
soon as an item is selected.

Comment 13

[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 14

[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 15

[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 16

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420