Closed Bug 32768 Opened 25 years ago Closed 21 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
(deleted), text/html
Details
patch that fixes the issue Neil/Daniel mention
(deleted), 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
Attached patch part 1 implementation of Joe's plan (obsolete) (deleted) — — Splinter Review
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-
Attached patch patch that always relativizes urls on paste (obsolete) (deleted) — — Splinter 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: 21 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: