Open Bug 805359 Opened 12 years ago Updated 8 years ago

Copy and paste link loses relative url

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Version:
SeaMonkey 2.10 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(seamonkey2.43 affected, seamonkey2.44 affected, seamonkey2.45 affected, seamonkey2.46 affected, seamonkey2.47 affected)

Tracking Flags:
Tracking Status
seamonkey2.43 --- affected
seamonkey2.44 --- affected
seamonkey2.45 --- affected
seamonkey2.46 --- affected
seamonkey2.47 --- affected

People

(Reporter: dgwest7, Unassigned)

References

Details

(Whiteboard: steps to reproduce in comment 4)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121010144125 Steps to reproduce: I copies some text set up as a link with URL relative to location. Actual results: When I pasted the link in another page, the relativity had gone. Expected results: The copied item should be accurately reproduced as the pasted item. I am sure it was working correctly just a few days ago, and I may have had an automatic update meantime. It's very useful when a link needs to be patsed to many pages. But now, that is not possible, and in fact the posted code produces a wrong address and hence an error. Very bad really - messed up hours of work already. But I have backtracked to version 2.12, and the problem is there too, so I am a little confused.
Composer or message composer I guess?
Sorry, yes Seamonkey Composer. I found the fault in the latest auto-download version,and have become mored with bactracking to find one that works. Maybe I am doing something wrong? If I turn xxxxxxxxxxxxxx into a link, then copy and paste it, the following HTML results <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <meta content="David West" name="author"> <title>xxxxxxxxx</title> </head> <body alink="#ffccff" bgcolor="#666666" link="#ffccff" text="#ffccff" vlink="#ffccff"> <a href="currency.html">xxxxxxxxxxxxxxxxxxxxxx</a><br> <br> <br> <br> <a href="file:///C:/Users/Inspiron/Documents/Website/enlightenment/vision/currency.html">xxxxxxxxxxxxxxxxxxxxxx</a><br> </body> </html> Notice the cange between
Can't reproduce this issue on both 2.13.2 and current trunk, can you provide detailed steps how you get this?
Component: General → Composer
Flags: needinfo?(dgwest7)
Okay, after receiving addition info from reporter I was able to reproduce issue on trunk. Steps to reproduce: 1) Create new page, save it to some location 2) Create a link to file in same location, set link relative 3) Copy link and paste it Expected results: Pasted link is relative Actual results: Link not relative and contain actual location
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dgwest7)
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: steps to reproduce in comment 4
Version: SeaMonkey 2.12 Branch → Trunk
CCing ehsan in case a low-level change is responsible for this.
Is this because the "URL is relative to page location" not checked? Would having it checked when pasting be sufficient? (I don't know. Just a drive-by query.)
So, this probably goes back to bug 613517, where we removed the functionality to relativize pasted based on the document's current location. I can't think of a way to fix this bug without reverting that code, but I don't want to have that behavior back for Firefox. I'd probably take a patch which brings that code back but makes it work only conditionally in SeaMonkey and when the document URI is a file URI. (In order to check whether we're in SeaMonkey, you should make sure that eEditorAllowInteraction is not set.)
I have got this bug for years, with Seamonkey Composer on Linux, and still now with v2.16. Indeed, I have always used Seamonkey Composer along with a shell script that checks for local links so that no bad link is uploaded to the web server.
if you have an image and use it to make a relative link to another page it works fine. Cut it and paste it in the same page (I use it monthly to re-arrange 12 months of magazine links so they move along one in a table) and it replaces the link with an absolute link. This stays EVEN WHEN YOU CHANGE IT BACK TO RELATIVE despite showing the relative link. When uploaded the link still wants to look at my desktop. Looked at it again in Seamonkey and the relative url is shown. When you look at the link in another composer the link is shown as the absolute version. The only way I can find to change it back to relative is to use the second composer (Amaya)!!
Still REPRODUCIBLE with English SeaMonkey 2.47a1 (NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0 Build 20160712001326 (Default Classic Theme) on German WIN7 64bit Version changed due to https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines#version
status-seamonkey2.43: --- → affected
status-seamonkey2.44: --- → affected
status-seamonkey2.45: --- → affected
status-seamonkey2.46: --- → affected
status-seamonkey2.47: --- → affected
Version: Trunk → SeaMonkey 2.12 Branch
Same effect with links to images. Original picture has relative link like <img src="hamster.png" alt="" width="1024" height="768"> After copy - paste the new picture has a link to <img src="file:///C:/.../hamster.png" alt="" width="1024" height="768">
Already REPRODUCIBLE SeaMonkey 2.10 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10 Was still ok with SeaMonkey 2.5 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20111121 Firefox/8.0.1
Keywords: regressionwindow-wanted
Version: SeaMonkey 2.12 Branch → SeaMonkey 2.10 Branch
(In reply to Rainer Bielefeld from comment #14) This seems to match with Target Milestone "mozilla12" of Bug 613517 (see Comment 7)?!
I think regression-window only will be required if suspect concerning root in fix for bug 613517 can not be confirmed.
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.