Closed Bug 122227 Opened 23 years ago Closed 23 years ago

Composer/nsIWebBrowserPersist is making relative links absolute when saving file from Composer

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: kinmoz, Assigned: Brade)

References

Details

(Keywords: dataloss, regression, topembed, Whiteboard: EDITORBASE+)

Attachments

(1 file, 1 obsolete file)

revised patch
2.67 KB, patch
adamlock
: review+
kinmoz
: superreview+
asa
: approval+
Details | Diff | Splinter Review
This bug was reported on n.p.m.editor. Kristofer <Kristofer@myrealbox.com> wrote: On the current build. Nightly. The I edited a page and just added a few sentenced and when I went to veiw it. I found that all the links on the Page where now pointing to the spot on th hard drive not relitive to each other. exaple. link was \page.htm now it was Z:\mozilla\...\page.htm There were many links on the page I was updating I didn't touch any of there properties. Just the text. So mozilla composer somehow automaticaly undone the relitve function on all the link on the page. It was a pain to fix. I went back to the previus build 2001122106 and it was fine on this build. The the last nightly had this bug.
this is mine...
Assignee: syd → brade
Keywords: regression
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9.9
*** Bug 122205 has been marked as a duplicate of this bug. ***
Laurel, you sent me an email on this issue. the issue is captured in this bug report.thanks.
Is this related to changes made to bug 90550?
Is composer using the persist object yet?
*** Bug 121977 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
yes, Composer is using persist. No, it's not really related to 90550. I've been thinking about this very issue all weekend (as well as the other issue which was filed recently)...
Request upping the severity to critical or at the very least major.
Kristofer, I've seen this problem on Mac OS 9.2 composer though.
Nominate for EDITORBASE (Kathy, do you agree? Remove it if you don't.)
Whiteboard: EDITORBASE
triage team says EDITORBASE+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: EDITORBASE → EDITORBASE+
This bug really MUST be fixed for milestone 0.9.8 (and not 0.9.9), since this bug makes the entire Composer module useless. It destroys entire web pages (*ALL* links!!!) just by opening them. This is "dataloss" (in addition to the extreme annoyance factor), therefore, Severity: *CRITICAL*. Also suggest Priority: *P2* and Target Milestone: Mozilla0.9.8. Please don't let this one slip.
*** Bug 123495 has been marked as a duplicate of this bug. ***
Bummer, this bug slipped, thus making the entire Composer module in 0.9.8 unusable. :( Now, how about setting an appropriate Priority and Severity?!
Severity: normal → critical
Changing summary to "place the blame" closer to the source. This is happening because Composer is now using the nsIWebBrowserPersists API to save files.
Summary: Composer is making relative links absolute. → nsIWebBrowserPersist is making relative links absolute when saving file from Composer
Adding dataloss keyword.
Keywords: dataloss
Summary: nsIWebBrowserPersist is making relative links absolute when saving file from Composer → Composer/nsIWebBrowserPersist is making relative links absolute when saving file from Composer
*** Bug 124409 has been marked as a duplicate of this bug. ***
*** Bug 124439 has been marked as a duplicate of this bug. ***
Noticed another oddity: All image links to .jpg files are changed to .jpeg This isn't noticable at first, because it ALSO makes a copy of image.jpg to image.jpeg. (Actually it munges the filenames more severely too - the first part of the original image name is not kept intact if there is an underscore in it. There may be more oddities too.) Discovered this all when i uploaded a page to web via manual ftp: all images were suddenly broken on web. A link to a counter, originally something like this: <img src="http://www.tele2.no/cgi-bin/Count.cgi?df=dark_something.dat&amp;ft=0&amp;dd=B"> was turned into simply <img src="Counter.gif"> That is the gif's name as it appears on the page once rendered. But in order to get it there in the first place, the original syntax is needed. So - the counter broke too.
Both the original problem and comments #19 show up in Mozilla build 0.9.8 Please mark this problem as critical.
I use the Editor daily, but this one forced me back to 0.9.7. I'm glad I use CVS, otherwise I would have lost *lots* of link info. This bug must be fixed ASAP.
I think this bug is fixed but I haven't checked all the duplicate bugs. Can someone else confirm or point me to a testcase that is broken?
Status: NEW → ASSIGNED
I checked with 0.9.8 -> bug is still there how i tested: html file on local drive (D:) - openen with composer - save (only put in a space) - open file with text editor -> links are all absolute (D:\...\...)
This won't be fixed in 0.9.8 branch! Right, Kathy? Please test trunk build.
Well I had the same experience yesterday and it really astonished me because I started working with the composer 0.9.5 and this problem came first on 0.9.8 I reedited the page with a computer where 0.9.7 is installed and that fixed the problem. So it seems that this bug was already solved!!
Seems this was fixed in bug 121980. Testing on a current CVS, Linux, editing a local file: If i select "preferences/composer/Retain original source" formatting of links will be fine, and images and files keep their original names. The "Pretty print" option is dangerous though. It means nothing to me, but sounds like a tempting option to try. I guess most only do that mistake once, since the result will likely be an undesired disaster of messed up links - it adds full local paths. I know there's a bug on the wording - it should be fixed ASAP.
With reference to comment 26, about pretty printing: "Pretty printing" in my experience (as a coder) refers to the way that the code is shown and means that that structure and the content of the code remain the same althought the use of whitespace will almost certainly change - i.e., it is purely a visual aspect. The composer needs to support this for those users who look at the source. Tidying the structure and hence makeing changing to the code, as opposed to the spacing can be useful although some degree of control over how would be useful. The first problem to solve is the naming. Is what is happening actually 'tidying' in a similar, but limited vein, to HtmlTidy?
Prettyprinting should affect ONLY whitespace. It shouldn't have any affect on whether links are translated. If it does, then there's a serious problem with the way nsIWebBrowserPersist is treating the output flags.
Akkana: i tested with a build only a couple of hours old. With "Pretty print" pref, saving is still as horked as when this bug was filed.
This bug is not about pretty printing; please take that issue to a different bug
Target Milestone: mozilla0.9.9 → mozilla1.0
Keywords: topembed
Kathy: the claim is that this serious url-rewriting bug only happens when the pref is set to prettyprint, not when it's set to retain formatting. If so, there's a serious miscommunication of flags going on that we definitely need to know about and fix. That said, I'm not seeing the bug myself. I edited a remote page, made a minor change, and did Save As, and all the relative links that were on the page are still relative. I tried both prettyprint and retain source formatting prefs, and I tried changing the dropdown in the save as window to "all files" thinking maybe it had something to do with the dropdown in the same place in the browser's save as for "web page, complete" which does rewriting. (It's confusing that those two dialogs look so similar but the dropdown does completely different things!) I have an idea, though: I've noticed that the browser's dropdown remembers when I switch from "Web page, complete" to "html only", so it must be setting a backend pref. I wonder if this is why some people see this and I don't? I tried setting my browser back to "Web page, complete" and still don't see rewriting when I save from the editor, but I didn't try very hard (no quit/restart). Re changing .jpg to .jpeg: if it's still doing that, I suggest filing that separately to adam lock. That sounds like unfriendly behavior but it's not related to saving from composer (unless it only happens from composer and not from the browser?) and it would be a shame to lose track of that issue.
Well I just changed a name on a hompage ( I edited a copy of the html file which I have locally on my pc) saved it transferred it to the server via ftp and all links were broken (no more relative links). I changend all the links and entered the relative adress manually but it made no change. My system is a Win98 SE I wonder why this bug appeared with 9.8 there seemed to be few problems with the composer??!
filed bug 126851
*** Bug 126851 has been marked as a duplicate of this bug. ***
What I have seen: - I have the bug also if "Pretty Printing" is not set. - If You look in the editor the html code after saving -> links are still relative. if I open the file with a texteditor it is allready absolute. After restart composer I saw also the absolute links in composer. -> for investigations allways look into a texteditor.
Depends on: 114951
*** Bug 127559 has been marked as a duplicate of this bug. ***
Hi R.K.A., I see that a solution for thr problem in Bug 127559 is shown here (do not select "pretty print" in composer- preferences), so that 127559 seems to be no longer a bug. But I cannot see any connection between the reasons of - Composer/nsIWebBrowserPersist is making relative links ... - Compser destroys html / touch between pictures
The bug seems to be resolved in dayly 2002030208 (WIN98, PC). I tested several times with links and pictures- addresses aud saw no problem
Kathy/Kin, can we mark this RESOLVED-FIXED? or are there still issues to be worked out ?
There are still problems; I hope to address this issue later this week.
I've noticed if you copy and paste images, it changes links from relative to absolute. This was in the 2002-03-07 build.
Nick: Thanks for the reminder, yes, that is a nasty problem we must fix! Brade: I can't find a bug on that!
regarding comment 41, that bug has been around for a LONG time (bug 32768). It is unrelated to this bug which is specific to saving.
with a fresh cvs, linux, links to name anchors in a page are given full local path
Comment on attachment 74962 [details] [diff] [review] don't do any link adjustments for Composer r=adamlock
Attachment #74962 - Flags: review+
Should PERSIST_FLAGS_FIXUP_LINKS_TO_DESTINATION be removed now? This removes the only code that uses it in the persist code: - nsCOMPtr<nsIURI> relativeURI; - relativeURI = (mPersistFlags & PERSIST_FLAGS_FIXUP_LINKS_TO_DESTINATION) - ? mTargetBaseURI : mCurrentBaseURI; Also, these seem to contrast each other? | webPersist.PERSIST_FLAGS_FIXUP_LINKS_TO_DESTINATION + | webPersist.PERSIST_FLAGS_DONT_FIXUP_LINKS
Attached patch revised patch — — Splinter Review
Attachment #74962 - Attachment is obsolete: true
Comment on attachment 75168 [details] [diff] [review] revised patch r=adamlock
Attachment #75168 - Flags: review+
Comment on attachment 75168 [details] [diff] [review] revised patch sr=kin@netscape.com
Attachment #75168 - Flags: superreview+
Comment on attachment 75168 [details] [diff] [review] revised patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75168 - Flags: approval+
fix was checked in earlier today Composer will no longer modify links.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
This looks good to me on 03-22 trunk. Marking VERIFIED. If anyone is still able to reproduce this problem, feel free to reopen this bug.
Status: RESOLVED → VERIFIED
The problem becomes more and more serious! I do not know, whether in tests for mozilla 1.0 the problem is really fixed. In the 0.9.9-branch problems are more serious than ever before. In earlier 0.9.x- Versions, the problem with "makes relative links absolute" and "renames jpg to jpeg" only happened with "pretty print" selected. In all my tests i hat selected "Retain original source formatting" Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020328(03) makes relative links absolute _just_when_the_file_is_loaded_ into the composer (in earlier 0.9.x- version the problems started with saving the html-file) and immediately saves all images in the folder where the html-file is located! Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020331(09) Same problems as in earlier 0.9.x- Versions with "pretty print" selected, but here too with "Retain original source formatting" selected
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Hm, I was not able to reproduce my reported Problem Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020328(03) makes relative links absolute _just_when_the_file_is_loaded_ .... May be I made a mistake in my tests ? All Other statements reproduced with 100% reliability One More Bug Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020328(03) saves images of the page althoug _not_ selected "save images and other ..." in the composer-preferences
Rainer Bielefield--I'm sorry you are seeing problems. I think the problems you are describing are not part of this particular bug but instead are covered in other bugs: * bug 134940 image links are being mangled (regression) * naming of image files (*.jpg vs *.jpeg) is completely unrelated to any prefs (there is a separate bug on this and it was fixed and verified) * pretty print output may not be "pretty" (I don't know the bug # offhand) (note: the prettyPrint bug has nothing to do with any url modifications) Re-resolving this bug as fixed since these issues are NOT related to the <a> changes that this bug is about.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
rainer bielefeld: I am sorry but I cannot reproduce your problem with my 0.9.9+ 04 02 version on Win98 . I just edited a page with lot of pics and lots of links but no link is absolute and the jpg files are jpg files!
marking verified again.
Status: RESOLVED → VERIFIED
Hi Croco Dil, so it ist, in Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020402 the Problems are solved again
*** Bug 149662 has been marked as a duplicate of this bug. ***
*** Bug 195807 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: