Closed Bug 32768 Opened 24 years ago Closed 20 years ago

Keep pasted links relative within same document

Categories

(Core :: DOM: Editor, defect, P2)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7final

People

(Reporter: akkzilla, Assigned: Brade)

References

Details

(Keywords: helpwanted, Whiteboard: [behavior] EDITORBASE-)

Attachments

(2 files, 2 obsolete files)

some notes on how to deal with relaitve link copy/paste
4.75 KB, text/html
Details
patch that fixes the issue Neil/Daniel mention
14.26 KB, patch
neil
: review+
dmosedale
: superreview+
Details | Diff | Splinter Review 
Split off from bug 23980:

We now make all links absolute when pasting.  But this probably isn't the right
thing to do: for example, relative links pasted within the same document should
stay relative, and it would be nice if relative links pasted between edit
windows editing files in the same directory could also stay relative.

The problem is that nsHTMLContentSinkStream doesn't know the url of the document
into which we're pasting (if indeed we're pasting at all), so for now I've set
the paste code in nsXIFFormatConverter to always set the "make absolute" flag. 
So the caller might have to figure this out, and tell the paste code; or is the
paste code smart enough to figure this out on its own?
Accepting, but not high priority unless someone makes a big deal out of it.
Status: NEW → ASSIGNED
Target Milestone: M17
Keywords: correctness, nsbeta3
Target Milestone: M17 → M18
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Priority: P3 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][p:2]
This turns out to be hard.

It's easy to tell the output sink to use relative vs. absolute links when
producing html.  
It's also easy for the editor to decide at paste time whether it's using mail
rules or not, and decide based on that what sort of pasting it wants to do (we
made pasted links absolute because of a request from mail; web page authors
obviously do not want this feature, since it will get links wrong if they're
copied from the local copy of the document, which isn't the absolute path it
will have when copied up to the web location).
The problem is that the clipboard does its conversion to html at copy time, and
by the time the paste happens, the html conversion is long since over with and
there's no way for the pasting client to tell the clipboard to use absolute vs.
relative link styles.

XIF paste would solve this, but there's no time (nor much inclination) to
implement that in the near future.  Failing that, we could use a different
clipboard mime type to represent "html with links left relative" vs. "html with
links made absolute", so that the pasting app could ask for the type it wanted
(the default for text/html being relative links, and mail compose could specify
absolute); but we certainly don't want to do that if the clipboard is still
converting to all formats on every copy (is it?)

Anyone have any other ideas?

In the meantime, alas, we'd better mark this Future Helpwanted (per Beppe).
Keywords: helpwanted
Whiteboard: [nsbeta3+][p:2] → [nsbeta3-]
Target Milestone: M18 → Future
Cc anthonyd; not sure which of us should own this.
*** Bug 73687 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta3-] → [behavior]
*** Bug 23980 has been marked as a duplicate of this bug. ***
Adding cmanske since he has been doing some related work which makes this
situation a lot better.
I've been finding this to be very annoying. I think it would be easy to fix once
bug 72583 is fixed. I think we should consider it for fixing ASAP.
Depends on: 72583
Target Milestone: Future → mozilla0.9.5
I've been talking to Joe about this.  Basically, we have no mechanism to do
this.  We don't save the original document location at copy time -- to do that
we'd have to add an extra data flavor to html copies (which we could do -- we
already have at least two extras to carry context info, but neither one has a
way of storing original url).  But even if we did that, we don't "look inside"
html paste or do any of the fixups that we do on other html inserts, so to do
this we'd have to rewrite html paste to do the same thing that html insert does.
 (IMO we should probably do this anyway, but we don't currently.)

Changing component to Editor Core (which it clearly is at this point, though it
might need a little tweaking in the serializer at some point) and milestone to
1.0 (arbitrary: that's where url rewriting for publishing lives, and at this
point this bug sounds much harder than that one).
Component: DOM to Text Conversion → Editor: Core
Target Milestone: mozilla0.9.5 → mozilla1.0
Instead of adding another flavor, a possible solution is to leave the URLs 
as-is, but the data copied to the clipboard would be a well-structured HTML 
document:
<!DOCTYPE ...>
<HTML>
<HEAD>
<BASE HREF="the-page-base">
</HEAD>
<BODY>
The copied data.
</BODY>
</HTML>

That might add some weight to the regular clipboard data, but atleast it looks 
standartish and doesn't introduce another data flavor.
Blocks: 104166
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Akkana: this needs to be done as part of publishing work, no?
Please change milestone to 0.9.8 or 0.9.9
Publishing needs to be able to rewrite URLs at publish time.
Smart pasting is different, because we don't know the document location from
which the url is coming.  Smart pasting is not a requirement for publishing AFAIK.
Ok, it may not be a requirement for publishing per se, but this is an important
issue. It is especially frustrating (and unnecessary) when you simply drag-n-drop 
some links or images from one place in a page to another and we convert relative 
image or link URLs to absolute.

One thing we could do (and, I suspect, should do) is just leave copied links as
relative -- don't absolutize them, and rely on publishing to do any absolutizing
that might need to be done.  (Of course, then we'd lose information in links
copied or dragged from unrelated pages.)

Hmm, oddly, Kathy isn't on the cc list, though I know she has opinions about
this issue and I think they may be opposite Charley's.  Adding her back.  I'm
happy to go either way for the non-smart link copy, but I don't know how to do
the smart link copy since Joe's copy contexts don't provide the necessary
information and inventing yet another flavor of copy context isn't something I'm
prepared to do any time soon.
I think we need to come up with a solution for this problem but I haven't
completely figured it out yet.

One scenario that will break if we make the change is when I copy a relative
link from one document and paste it into another document (or copy from a
browser window and paste into composer or mail compose).  Another scenario is if
the destination page is unsaved.

Can we do something like Ilya suggests in comment 12?
Can we put both there on copy and have paste do the smart thing by removing one
of them?
Maybe we should always leave it absolute on copy but relativize it if possible
(always) on paste?
Could we put both the exact URL text and the absolute version on the clipboard
when copying? The when we paste, we should:
1. Use the exact version if target is the same as source.
2. a. Use the absolute version when target is different or a new page.
   b. Then let the user's publishing prefs relating to "always make links 
      relative" tells us to convert this absolute URL to relative (if possible)

This would preserve absolute links that the user might really want to keep 
while relativizing when appropriate, since most users will use the default pref
state to always relativize.

We don't want to put both versions on the clipboard -- that means taking up
twice the amount of memory, which could be significant on a big page.

I like Ilya's solution too, but when I discussed this with Joe my understanding
was that he thought it wouldn't work and that the only solution was to add yet
another context flavor.  I don't understand why -- perhaps Joe can elaborate? 
Or perhaps this bug should be passed to him, since he's the expert on the extra
clipboard flavors ...
After looking at Ilya's solution, I agree that it looks attractive (if it worked)!
BTW, I think we always write the current page location to a <base> tag when
we save.

Would it be possible to put the base href attribute value (as charley noted) 
in the clipboard too? Then when we paste check to see if we are pasting into the 
same document, and if so leave it as a relative link. But, if we are pasting 
outside of the document, prepend the base href attribute to the URL?
I agree with Beppe.
I think the only difference between my suggestion in #18 and Ilyas' in #12 
(or variations of including <base> tag) is that an extra URL is included in the 
cliboard just once if <base> is used, while my suggestion in #18 requires an 
extra URL for each link/image in the selection. Including just one <base> URL 
seems better.

Seems we all agree on what should happen, but we need to know from Joe what the
issues are re getting this information into the clipboard context.  Joe's the
only one who knows how that works.  Reassigning; I can take it back to do the
editor paste/rewriting work once we have the base url available.
Assignee: akkana → jfrancis
Status: ASSIGNED → NEW
Ilya's suggestion makes a lot of sense, but unfortunately I know better.  Given 
the relationship between the different data flaovrs at html copy time, wrapping 
the main data flavor with a docuemnt wrapper would be confusing in the 
implementation.  Other than that it's a great idea.  

So I think what should be done is:
1) html copy adds a flavor with the base url
2) main data flavor should copy links exaclty as they are in source doc (relative 
stay relative, absolute stay absolute)
3) paste code should compare copy base url with destination base url, and if they 
are the same, leave links alone.  If they are different, it should convert all 
links to absolute.  This will require groveling through all the pasted content, 
which is something we don't currently have to do and may slow down large pastes a 
bit.

Note that 2) implies that copying from Mozilla and pasting into another app (that 
only knows about main data flavor) will mean the relative links will stay 
relative, which means those links will break unless that app is editing something 
with same base url.

removing myself from the cc list
Using Composer in build 2002-04-15..  I copy and paste links and it converts
them to relative links.  It doesn't help the flow of creating though (have to be
careful to not create any relative links and then you have to check/fix any later)

- Nick
IMO, any attempt to alter links to do "the right thing" when
pasting is doomed.  Too often the document you're pasting to
is in a temporary place, or has never been saved at all.
Count me firmly on the side of "don't touch the link"

It might be handy if there were a visual cue in composer to 
identify relative vs. absolute links - making them a different
color for example.  Then the one "red link" on a page would
stand out like a sore thumb.

> It might be handy if there were a visual cue in composer to
> identify relative vs. absolute links - making them a different
> color for example.

Nice idea!  Of course, it would require that we be able to control link color at
all.  Right now we don't even honor the page-specified link colors, so pages
with dark backgrounds are all but unusable in composer (bug 57757).  You should
probably file that as a separate RFE, dependant on that bug.
I like the idea of some visual cue, but I don't think link color is the right one.
As Akkana mentions, we have a bug to observe the author's color, so any fixed
color because of relative vs. absolute would probably not be apprectiated.
Some other CSS trick is possible; maybe a border? An icon before the link (like
we do for Named anchor)?

I think the problem of hidden absolute links is well worth putting effort into.
 These are a trap which ordinary users fall into easily, and which require a
great deal of effort for experienced users to detect.  For the purposes of this
discussion I will use the term "link" to refer to both to hyperlinks (specifying
what URL the browser will go to when clicked) and to the addresses used for
images etc.  I am not sure if this bug refers to just the former, but the 
problem seems to be identical for both types of "link" I am referring to.

I can think of three classes of link, but I guess there are others:

1 - Relative:   blah.jpg ;  ../aa/bb.html  etc.;  /aa/bb.html
    (The last one is a bit of a worry, since whether it works or not 
    depends on where the original file lives in the server.  For 
    instance I test files for my main web site in a sub-directory
    /fp/ on a server on my LAN.  URLs starting with '/' are not truly
    relative and should probably be avoided, but they are a convenience
    to the designer when making a bunch of pages which could live at
    various directory depths in the final server.)
    
2 - Absolute HTTP/FTP etc.   http://xxx.yyy.zzz/aa/bb.html

3 - File system absolute.    file:///Q:/aa/bb.html

In my experience using N4.x and now Mozilla for quite a few years, the problem
is entirely with the file system absolute links.  This is both for links to
other pages and for the addresses of images.  Generally, what began as a
relative link I manually created becomes a file system absolute link after a
copy and paste operation.   (There used to be a problem entering image and URL
addresses which made the file-system absolute, unless I edited it back to just
the file and relative path name, but the current arrangement of doing this
automatically is fine for me.)

This hidden changing of the link is bad enough.  But what is worse is that the
results typically work fine on the computer which is being used to create the
page.   Of course they don't work on almost any other computer.  So the damage
persists, sometimes for years, affecting potentially thousands of web site
users, with the designer being oblivious to the problem.   I have found such
problems in my site which persisted for years and I have seen the same problems
in other people's sites.

Here, in detail, is what can happen.

I using a Win2k machine to run Mozilla, editing pages accessed via the LAN on a
Linux machine.   Here is an example URL of an image as it appears to the web
site user, the URL of a page which uses that image, and the paths Mozilla uses
to access them when editing:

   http://www.firstpr.com.au/rwi/dfish/close-up.jpg     
http://www.firstpr.com.au/rwi/dfish/index.html


   file:///Q:/fp/rwi/dfish/close-up.jpg
   file:///Q:/fp/rwi/dfish/index.html

When editing this page, if I copy and paste an image, or a hyperlink, or any
part of the page containing them, then what was:

   close-up.jpg

becomes:

   file:///Q:/fp/rwi/dfish/close-up.jpg

without any warning, or any visible change.

I can test the page via the file system on the Win2k machine using any browser,
it it looks fine.  

I can test the page on the local Linux web server using any browser on the Win2k
machine, via the URL:

   http://blah.firstpr.com.au/fp/rwi/dfish/index.html

and everything looks fine.

I can test the page after it is loaded onto the real www.firstpr.com.au web
server from the Win2k machine and still everything looks fine to me.   I used to
test pages using another machine, which happens to be a Win98 dogs-body with a
cable modem, and these errors still remained invisible, because it too accessed
the Linux machine via a SAMBA mount "Q:".  But I altered this to "P:" to smoke
out such file-system links in my pages.

After having users report problems which turned out to have been there for two
years or more, I finally got systematic about finding these problems.   I
methodically searched all my HTML files for any occurrence of "/fp".   

   (The best way I found, was to use Z-Tree - a fine Windows
    file browser from http://www.ztree.com - to view all the 
    .html files in the directory and subdirectories of 
    file:///Q:/fp/, list them all with the showall function
    and then search them all with a single command for "/fp".)

I found quite a few occurrences.  I could also have searched for "file:".

These file-system relative URLs are an invisible, time-wasting,
communcation-disrupting pox all over the Web!

Unless you are making an HTML page which is only going to be viewed via the file
system, rather than via a web server, then file-system relative links, image
addresses or whatever mean the page is faulty.   So I would support a flashing
warning beacon on the menu if the current file contains any such references.
Then, there could be a search facility to find them, and/or flashing warnings in
the page wherever they occur.

With a recent Mozilla release, (2002061104) I can do the perfectly ordinary and
often necessary operation of copying and pasting an image such as the one I
described and its address changes to a file-system relative one as described
above.   

If it could be assumed that the user never wanted to create pages to be viewed
only by the file system (perhaps make this a user-settable option, defaulting to
making pages not for file-system viewing) then I would think it is practical to 
copy a relative link such as:

   close-up.jpg

so that in the clipboard it becomes:

   file:///Q:/fp/rwi/dfish/close-up.jpg

Then, if this is pasted into a page in the directory:

   file:///Q:/fp/rwi/dfish/

that the Lizard would be evolved enough to turn the link back into:

    close-up.jpg

Further evolution would have it paste into a file which lives in
   
   file:///Q:/fp/rwi/smem/

so that the link would be:

   ../rwi/close-up.jpg


In my experience, I have never had any problems with the second kind of absolute
links: http://aaa.bbb.ccc/xyz.html etc.

The real problems are:

1 - That copy/paste changes a relative link to a file-system absolute link.
    (Because of the view that since the clipboard has no base URL, it must
     contain absolute references, which can only be via the file system if
     the file being edited is accessed via the file system.  But if a 
     page from a live web server is edited, without being saved to the
     file system, then copy and paste from this live page to a file
     system accessed page will result in an absolute http//.... link.)

2 - It does this without warning or any visible change to the author at 
    the time.

3 - The problem will probably not be visible to the author when they test
    the page from its real or a temporary location on a web server.

4 - The image, hyperlink or whatever is non-functional for the user and
    the "file-not-found" or broken image thingo is hardly conducive to
    them reporting the matter to the author, which they shouldn't have
    to do anyway.   

Alternative methods of finding the problem, such as searches of the raw HTML of
each or all pages for "file://", or scrutiny of httpd error logs, are arduous
and can only be done once the page has been saved.

There may be other aspects of the problem, but what I have described here is
certainly a problem for me, and for lots of other sites.

There is another problem which this one reminds me of, but which may be beyond
the scope of Mozilla.  It shows up on web sites in much the same way as the
file-system absolute hyperlinks and image addresses.  This is the problem of
developing sites on Windoze via the file system which is case-insenstive, so for
some reason having "close-up.JPG" works fine when editing or viewing via the
file system, but does not work on the web server.
 
disclaimer: I have read and do understand the comments above

Is this bug still valid?  What are the detailed steps to produce a saved or
published file with non-relative urls (inappropriately)?

My belief is that when files are saved or published, urls are converted to
relative if possible.  Any edge cases for this should be reported as separate bugs.
rw: Great analysis! But as Kathy points out, with the new Publishing feature,
we pretty much solve the problem for images *if* you publish a local html page 
*and* the images to a web server. In that case, the image URLs are made relative
to the new web address.
But we do still have the problem for hyperlinks. Thus we should be doing
something similar for the "href" attributes as we do for image "src". This is 
more difficult, obviously, since we don't know if/when a the page referenced by 
the "file:" href will alsobe published. This gets into the area of full site 
management and uploading > 1 HTML file at a time, which we hope to address in
the next major release cycle.
So I do believe we still do have an important problem to solve here.

I have never used the Publish feature.  I edit HTML files and put other things 
in the directories such as graphic files, MP3s etc. and indeed entire 
directories of stuff which Composer has no way of knowing about.  I do this via 
the LAN with SAMBA giving access to the web server directories of a local Linux 
machine.   That machine is on the Net, and quite a lot of what I do is simply 
for use from that server - mainly for friends.  So I am editing live HTML files.

When I am editing HTML for one of my remote main web sites, hosted in the USA, I 
am editing files in sub-directories of the local Linux machine.  I need to be 
able to test the HTML and all other files etc. there, before I FTP them to the 
server in the USA.

Then I want to use an FTP program on my cable modem machine to upload things 
only when I am happy with them.   So I want a single way of uploading files to 
the real web server, not some split system of using an FTP program and Mozilla's 
Publish feature.

Even if I was to use the Publish feature, I don't like the idea, as I understand 
it, of the contents of files being transformed in the process, as Charles' 
message above implies.  That would mean all sorts of potential for error and the 
need for me to test the page only after it was on the real web server.   

I expect to be able to test the page on a local web server, which is also 
accessible by the file system from the machine I run Composer on.  So as I wrote 
above, I can be editing the file and also browsing it from this or from other 
machines on the LAN.  I can change something, save and in the browser do a 
reload.  So the test cycle is reduced to a few seconds.

If, as I understand it, Publish involves some transformation of the data between 
what is in the local file and what is FTPed to the final web server, then this 
would mean that I have no local copy of my web site, which is the last thing I 
want.  I need a local copy for backup purposes, and so I can FTP the lot up with 
 a single command (ncftp if I remember) if I need to change hosting companies.  
I did this once with a shell command when I was a thousand miles from home.  
Alternatively, if the Publish feature transforms the local file, then this makes 
me nervous as well, since a single command does multiple automagic 
transformations without my explicit involvement.   It also precludes proper 
testing of the file until I do this Publish thing.

This is a long way of saying that although I only have a vague idea of what 
Publish does, I have many reasons for not wanting to use it - and therefore for 
not looking further into what it does.

I would think that many other people want to stick to the simplest, direct, 
concrete, nothing-more-automagic-than-needs-to-be approach which I use, for the 
same or perhaps other reasons.  We all know what rot sets in when things become 
too smarty-pants!  Already there are smarty-pants features in Mozilla which have 
benefits but also costs.  For instance the way ^L on "http://x.y.z" 
automatically puts this into the link address.  Its good in many ways, but it 
violates the default behaviour which applies to doing the same for an image or 
ordinary piece of text, so requiring me to modify my standard approach 
(virtually a reflex reaction, except now I have to stop and think of what I am 
applying the link to) of having the URL in the clipboard and then ^L ^V to make 
the link.   I find myself doing this sometimes with "http://x.y.z" and so making 
the link address repeat twice, which may not be visible to me in the small text 
box, and which I may not pick up in testing.   I only mention this to illustrate 
that direct, simple, consistent behaviour in a program is a real asset, and to 
caution against the temptation to think that more and more complex "features" 
are necessarily a good idea, or that people will discover them, invest the time 
to learn what they do, or want to use them even if they do correctly understand 
them.

Lots of people tell me how they like my sites - how they load really quickly.  
The pages are direct and sometimes attractive, whilst sometimes being a bit 
ragged and bohemian.  They are not like some corporate movie trailer - the model 
is pages as of a book, and they are usually meant to be printed. They are not 
infested with Javascript, Flash, animated gifs, frames or image-maps.  Nor are 
my sites goosestepping database driven PHP creations.  All the image files have 
their sizes specified in the HTML, which greatly speeds the display of the page. 
 There's no CSS, special server requirements or any other dingly-danglies.  
No-one has ever complained about the sites not working on some browser.  All the 
work has been done with N4.x and now Mozilla using the edit, test and FTP 
procedures I have described, and I say this at the bottom of the main pages.

  - Robin Whittle     http://www.firstpr.com.au  http://fondlyandfirmly.com

The trunk is the wave of the future!
Target Milestone: mozilla1.0.1 → mozilla1.1beta
The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.
Target Milestone: mozilla1.1beta → mozilla1.2beta
Target Milestone: mozilla1.2beta → M1
TM = M1 -> Was that deliberate?
*** Bug 163163 has been marked as a duplicate of this bug. ***
Fully agreed with Robin.

If add an option "Do not use file: links in Composer" which do not allows to use
fixed 'file:' links (only relative and fixed non-file) it almost completely
resolve the problem for Composer's users. 
I understand it's not an ideal way but very good workaround which is much better
than current situation.

Even if this way produce an incorrect result the error could be easyly found on
local filesystem. Now it is not possible now.

As I understand from #5 this solution will not required a much work.
We need to get folks together and talk about this one.  We have a couple of 
choices on how to proceed.
Status: NEW → ASSIGNED
I think that the best solution right now is to:
 1) encourage authors to save their page asap
 2) when inserting pasted (or drag/dropped) content, the url is made relative if
possible (there is an api that makes this easy)
I hope you all don't mind, but I wanted to just throw in a comment here. I
copied a document locally that had a TOC on the top of the document (where each
line item had a link pointing to a named anchor) and the related heading items
down in the document had the assocaited named anchors. The named anchor
references were all absolute references, but the original document had all
relative references. To get the linking to work correctly on the server (no, I
did not use our publish option) I had to go through and strip out all of the
data before the # (hash) symbol -- that was very, very annoying.
nominating...
Whiteboard: [behavior] → [behavior] EDITORBASE
*** Bug 164024 has been marked as a duplicate of this bug. ***
EDITORBASE-. nsbeta1+
Keywords: nsbeta1+
Whiteboard: [behavior] EDITORBASE → [behavior] EDITORBASE-
The proposed solution in #45 looks very good.
IMHO the first thing that needs to be done is to paste relative links as
relative when copied/pasted within the same document or between documents.
Additions like "re-relativize" and figure out how to change links when pages are
saved or published can be implemented later.

I guess this means that 
- the base url of the source document has to be placed in an auxiliary data flavor.
- at paste time the links have to be created as relative.

I know not al the problems are solved with these two steps but at least problems
are visual when editing. Don't get me wrong. A complete solution is, of course,
much better. This bug is 'alive' for almost 2 years so if I have to choose
between a quick solution for the (IMO) most annoying thing in the composer
(converting relative links invisible to absolute links) and a long term complete
solution I prefer the quick one.

*** Bug 147291 has been marked as a duplicate of this bug. ***
*** Bug 185057 has been marked as a duplicate of this bug. ***
*** Bug 190137 has been marked as a duplicate of this bug. ***
*** Bug 198951 has been marked as a duplicate of this bug. ***
*** Bug 215264 has been marked as a duplicate of this bug. ***
*** Bug 215034 has been marked as a duplicate of this bug. ***
*** Bug 216504 has been marked as a duplicate of this bug. ***
Hmmm, the Target Milestone is very revealing. "M1" indeed, that was a while back.
*** Bug 217003 has been marked as a duplicate of this bug. ***
*** Bug 218571 has been marked as a duplicate of this bug. ***
I'm really tired of getting bit by this bug, especially when I just drag an
image to a new location on the same page.   I would be much happier if pastes
were ALWAYS RELATIVE when editing web pages.  Maybe we could add a preference
for this?

CCing Daniel Glazman
Joe--This is the start of addressing this bug.	This changes the "copy" code to
put the source url onto the clipboard.	(Still to do: drags initiated in
browser or composer)  Comments?
Attachment #132816 - Flags: review?(mozeditor)
Kathy, does this get the url of the source document, or the baseurl of the
source document (which is a different thing altogether).  It's the baseurl that
the copied relative links are relative from - so that's the information we need
to pass thru to the paste end.
Attachment #132816 - Attachment is obsolete: true
Attachment #132816 - Flags: review?(mozeditor) → review-
This patch doesn't completely address all of Joe's concerns/issues/suggestions
but I wanted to post it as a first attempt to get feedback and solicit others
to test it.  Lastly, I want to post this patch so it doesn't get lost on my
computer.  I haven't had a chance to do much testing myself.  I did copy/paste
within the same documents and tested anchors/links and images and saw that
absolute links were made relative and relative links remained relative (of
course in reality they were made absolute and then made relative again).

Improvements that could be made to the patch:
 * only relativize urls that were relative on copy
 * handle base url (currently it's ignored)
 * possibly there are some CSS urls or JS or ? that aren't relativized (but
maybe they aren't made absolute either?)

Comments? Feedback?
*** Bug 226930 has been marked as a duplicate of this bug. ***
Attachment #136319 - Flags: review?(daniel)
Attachment #136319 - Flags: review?(daniel) → review+
Comment on attachment 136319 [details] [diff] [review]
patch that always relativizes urls on paste

r=daniel@glazman.org modulo the name of RelativizeURIInFragment() that I find
badly chosen since it applies to a NodeList and not a DocumentFragment.
I am holding my r= since I think this code is not going far enough and should
relativize also the nodes INSIDE the nodelist's node in RelativizeURIInFragment().
Attachment #136319 - Attachment is obsolete: true
*** Bug 228199 has been marked as a duplicate of this bug. ***
Attachment #141342 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 141342 [details] [diff] [review]
patch that fixes the issue Neil/Daniel mention

r=me assuming as discussed on irc that you fixed the nits and tested it well.
Attachment #141342 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 141342 [details] [diff] [review]
patch that fixes the issue Neil/Daniel mention

also r=daniel@glazman.org
Thanks for fixing that issue Kathy.
Comment on attachment 141342 [details] [diff] [review]
patch that fixes the issue Neil/Daniel mention

>+  nsCOMPtr<nsIURL> destURL = do_QueryInterface(destDoc->GetDocumentURL());
I had to change this to GetDocumentURI to get this to compile, but apart from
that it seems to work on a sample page.
Comment on attachment 141342 [details] [diff] [review]
patch that fixes the issue Neil/Daniel mention

>+        if (!newRelativePath.IsEmpty())
An empty path is actually a valid relative URI... unfortunately no editor UI
supports it...
Attachment #141342 - Flags: superreview?(sfraser)
Comment on attachment 141342 [details] [diff] [review]
patch that fixes the issue Neil/Daniel mention

To help the compiler, you may wish to mark your NS_NAMED_LITERAL_STRINGs as
|const|, however, I've filed bug 235870 to get this done in the macro, where it
probably really belongs.

There are several cases where |if| is on the same line as |return|.  This makes
it impossible in most debuggers to set a breakpoint that triggers only in the
failure case.  I'd suggest changing this, but it's up to you.

sr=dmose with or without these tweaks.
Attachment #141342 - Flags: superreview?(sfraser) → superreview+
*** Bug 237258 has been marked as a duplicate of this bug. ***
*** Bug 237497 has been marked as a duplicate of this bug. ***
I believe this bug is now fixed such that it can be resolved fixed.  However,
I've seen comments in other bugs that this bug is not fixed.  Could someone
please put very specific steps on how to reproduce bugs where saved files with
relative links get saved with absolute links?  Thanks!
Assignee: mozeditor → brade
Status: ASSIGNED → NEW
OS: Linux → All
Hardware: PC → All
Target Milestone: M1 → mozilla1.7final
I just edited a page with a relative link,  selected the link, copied it, pasted
it to a new document, pulled up link properties, and *BAM*, no longer a relative
link. 

Not fixed in 1.7B on Windows 98.


Tested it with Mozilla 1.7B (Build ID: 2004031608) on Windows2000. Unfortunately
a relative link is made absolute after copy/paste.
Exact steps to reproduce the bug (composer is in CSS mode) :

- [ctrl][Shift][N] to create a blank composer page
- save the newly created page locally.
- [Alt][I][I] then click on "browse" to add an image
- [Alt][I][I] then click on "browse" to add another image.
- Add text after the 2 images and create a link with it.

Here's the source at this point :
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title></title>
<meta content="Eric" name="author">
</head>
<body>
<img alt="" src="icon-link1.gif" style="width: 32px; height: 32px;"><img
alt="" src="icon-mail1.gif" style="width: 32px; height: 32px;"><br>
<a href="link.html">test</a><br>
</body>
</html>

Now, I will put the first image after the second one and move the text between
the two

First method:
- Select the image
- [Ctrl][X]
- Move the cursor
- [Ctrl][V]
- Select the text
- [Ctrl][X]
- Move the cursor
- [Ctrl][V]

Here's the source now :
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title></title>
<meta content="Eric" name="author">
</head>
<body>
<img alt="" src="icon-mail1.gif" style="width: 32px; height: 32px;"><a
href="file:///C:/Mes%20Documents/internet/Test%20Mozilla/link.html">test</a><img
alt=""
src="file:///C:/Mes%20Documents/internet/Test%20Mozilla/icon-link1.gif"
style="width: 32px; height: 32px;"><br>
<br>
<br>
</body>
</html>

-------------------
back to the "clean" source.
I now do the same operations by selecting the first image and dragging 
it to the desired place, then dragging the text between the two images.

(exactly the same source as after the first method)

------------------------------------------
Can be reproduced each time.

Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7a) Gecko/20040219

Tested on 1.7a / win2k   - the bug was also present in all previous versions I
tried (back to 1.0 and before).

Also note that I saved the file before adding images.

If I added the images before saving the new file, they would have been in the
file:/// format from the start, which is normal from a programmer's perspective
since before being saved, the new page's path is unknown.
However, adding images to a new page *before* saving it for the first time is
what most users would do, so it should be taken care of.

To solve the problem, all local absolute paths should be translated into
relative paths when the page is saved (have it's own path resolved) for the
first time (or every time it's saved).

I (now again) hope to see it fixed.

Eric.
Robert Eden (comment 75) -- It's not clear from your steps that you saved the
2nd document.  If the document isn't saved, it can't be a relative link (or it
would be broken).  Please be sure to save the new file and test again.  Thanks!

G. J. Werler (comment 76) -- Unfortunately you don't describe at all how to
reproduce the problem you see in 1.7beta so I can't tell if you are seeing this
bug or something else.  Please give specific steps (such as in comment 77).

Eric (comment 77) -- Great comments / thanks for all the details!  Could you
please test again with a newer build (1.7beta or a nightly build)?  The fix I
made for this bug landed in early March.  Hopefully the steps you have in
comment 77 will work for you in a newer build.  :-)
Status: NEW → ASSIGNED
Sorry Kathy, the problem was so obvious that I didn't think it needed a detailed
description. But when I tried to reproduce the bug at home (on a WindowsXP Pro
machine) with a different Mozilla 1.7b build (2004031616) I noticed why you need
this info. With this build the problems seems to be resolved. Great! Here are
the steps that I performed: 

1. Created a new html file index.html and index2.html in the same directory
(c:\temp)
Source index.html:
<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>page title</title>
<meta content="G.J.Werler" name="author">
</head>
<body><a href="index2.html">Hello World</a><br>
<br>
</body></html>

2. Selected the linked "Hello World" text an copied it (CTRL-C)
3. Moved the cursor one line below and pasted the text: (CTRL-V)

This time the source looked like expected:
<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>page title</title>
<meta content="G.J.Werler" name="author">
</head>
<body><a href="index2.html">Hello World</a><br>
<a href="index2.html">Hello World</a><br>
</body></html>

but when I tried this earlier on a Windows2000 OS with Mozilla 1.7b build
2004031608 it gave this result:
<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>page title</title>
<meta content="G.J.Werler" name="author">
</head>
<body><a href="index2.html">Hello World</a><br>
<a href="file:///C:/temp/index2.html">Hello World</a><br>
</body></html>

I tried Eric's test and all the links where left relative (as supposed). So it
looks like this problem is solved in the latest 1.7b builds. Thanks Kathy!

Eric, can you replace your 1.7a with the latest 1.7b (I downloaded mine from
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7b/mozilla-win32-1.7b-installer.exe)
and do the same test again?
**** I STAND CORRECTED *****

This is fixed in 1.7B on Win99. 

Only "catch", as brade@comcast.net said in Comment #78 the destintation page
must have a filename associated with it.

It would be nice if a warning showed up when trying to paste a relative link to
a page without a filename.  I'm sure a special case already had to be written
into the code.  That may avoid future bug reports.

Robert
Robert Eden (comment 80) -- please file a new bug with that "feature" request
and cc me on it.

resolving this as fixed per comment 79 and comment 80
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Well done !

As suggested in comment 78 & comment 79, I made the exact same tests using the
latest nightly build of Mozilla (Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR;
rv:1.7b) Gecko/20040402) and yes, the issue is solved. It's been a long way, but
it seems very solid. I even tried to cut/paste text with relative links between
pages located in different directory levels and the relative paths are properly
adjusted (tried hard, could not find any situation where it does not work as
expected). 

The only problem that is left, as mentionned in comment 80, comment 78 & mine is
the problem with pages that have not yet been saved (unresolved path) and that
still use, and save the absolute local path.

The solution proposed in comment 80 would be interresting. Another way to solve
the problem would be to leave the absolute local path notation until the user
saves the file and then change all these locations to their relative equivalent.
That's how it behaves when such a link is present in a page at the time it is
published.

Unless there are some situations where it's desirable to keep the absolute local
path notation (can't think of any, but I might be wrong), I don't even see the
need to bother asking the user before making the links relative.

As mentionned in comment 80 this is an enhancement.

Thanks for fixing that longstanding bug, now, at last, I can recommand using
Mozilla's composer to non technical peoples who just want to do simple updates
to their pages without being worried that they'll come back to me complaining
about their broken images. 

Eric

PS : After all, maybe #76 in "the other bug" was an April Fool's attempt to
celebrate the resolution of this bug ... and I fell for it ;-)
(In reply to comment #81)
> Robert Eden (comment 80) -- please file a new bug with that "feature" request
> and cc me on it.

Done: Bug 239489 has been opened (posted here in case anyone else is interested)


nice job Kathy.
I didn't read through all these nearly ten year old comments, but the bug doesn't seem to be fixed at all for me:

When in the Composer inserting a picture (e.g. .jpg) using the 'insert image' feature, one can choose, whether the URL is relative or absolute. However, when later moving the picture by cut-and-paste all associated URLs (that of the picture itself and any link that may be associated with it) become automatically absolute.

I find this a nuisance as I am often re-arrange pictures while developing a page. Adjusting the URLs is very tedious and time consuming. The file structure on my computer is exactly the same as the one of the server, so that in both cases the same relative URLs work.

Any (time-saving) suggestions ?

Eberhard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: