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)
SeaMonkey
Composer
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: kinmoz, Assigned: Brade)
References
Details
(Keywords: dataloss, regression, topembed, Whiteboard: EDITORBASE+)
Attachments
(1 file, 1 obsolete file)
(deleted),
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.
Assignee | ||
Comment 1•23 years ago
|
||
this is mine...
Assignee: syd → brade
Keywords: regression
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9.9
Comment 2•23 years ago
|
||
*** 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.
Comment 6•23 years ago
|
||
*** Bug 121977 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 7•23 years ago
|
||
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)...
Comment 8•23 years ago
|
||
Request upping the severity to critical or at the very least major.
Comment 10•23 years ago
|
||
Nominate for EDITORBASE (Kathy, do you agree? Remove it if you don't.)
Whiteboard: EDITORBASE
Comment 11•23 years ago
|
||
triage team says EDITORBASE+
Comment 12•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
*** Bug 123495 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
Bummer, this bug slipped, thus making the entire Composer module in 0.9.8
unusable. :(
Now, how about setting an appropriate Priority and Severity?!
Comment 15•23 years ago
|
||
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
Assignee | ||
Updated•23 years ago
|
Summary: nsIWebBrowserPersist is making relative links absolute when saving file from Composer → Composer/nsIWebBrowserPersist is making relative links absolute when saving file from Composer
Comment 17•23 years ago
|
||
*** Bug 124409 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
*** Bug 124439 has been marked as a duplicate of this bug. ***
Comment 19•23 years ago
|
||
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&ft=0&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.
Comment 20•23 years ago
|
||
Both the original problem and comments #19 show up in Mozilla build 0.9.8
Please mark this problem as critical.
Comment 21•23 years ago
|
||
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.
Assignee | ||
Comment 22•23 years ago
|
||
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
Comment 23•23 years ago
|
||
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:\...\...)
Comment 24•23 years ago
|
||
This won't be fixed in 0.9.8 branch! Right, Kathy?
Please test trunk build.
Comment 25•23 years ago
|
||
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!!
Comment 26•23 years ago
|
||
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.
Comment 27•23 years ago
|
||
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?
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
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.
Assignee | ||
Comment 30•23 years ago
|
||
This bug is not about pretty printing; please take that issue to a different bug
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
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??!
Comment 33•23 years ago
|
||
filed bug 126851
Comment 34•23 years ago
|
||
*** Bug 126851 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
*** Bug 127559 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
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
Comment 38•23 years ago
|
||
The bug seems to be resolved in dayly 2002030208 (WIN98, PC).
I tested several times with links and pictures- addresses aud saw no problem
Comment 39•23 years ago
|
||
Kathy/Kin, can we mark this RESOLVED-FIXED? or are there still issues to be
worked out ?
Assignee | ||
Comment 40•23 years ago
|
||
There are still problems; I hope to address this issue later this week.
Comment 41•23 years ago
|
||
I've noticed if you copy and paste images, it changes links from relative to
absolute. This was in the 2002-03-07 build.
Comment 42•23 years ago
|
||
Nick: Thanks for the reminder, yes, that is a nasty problem we must fix!
Brade: I can't find a bug on that!
Assignee | ||
Comment 43•23 years ago
|
||
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.
Comment 44•23 years ago
|
||
with a fresh cvs, linux, links to name anchors in a page are given full local path
Assignee | ||
Comment 45•23 years ago
|
||
Comment 46•23 years ago
|
||
Comment on attachment 74962 [details] [diff] [review]
don't do any link adjustments for Composer
r=adamlock
Attachment #74962 -
Flags: review+
Reporter | ||
Comment 47•23 years ago
|
||
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
Assignee | ||
Comment 48•23 years ago
|
||
Attachment #74962 -
Attachment is obsolete: true
Comment 49•23 years ago
|
||
Comment on attachment 75168 [details] [diff] [review]
revised patch
r=adamlock
Attachment #75168 -
Flags: review+
Reporter | ||
Comment 50•23 years ago
|
||
Attachment #75168 -
Flags: superreview+
Comment 51•23 years ago
|
||
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+
Assignee | ||
Comment 52•23 years ago
|
||
fix was checked in earlier today
Composer will no longer modify links.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 53•23 years ago
|
||
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
Comment 54•23 years ago
|
||
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 → ---
Comment 55•23 years ago
|
||
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
Assignee | ||
Comment 56•23 years ago
|
||
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
Comment 57•23 years ago
|
||
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!
Comment 59•23 years ago
|
||
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
Comment 60•22 years ago
|
||
*** Bug 149662 has been marked as a duplicate of this bug. ***
Comment 61•21 years ago
|
||
*** Bug 195807 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•