Regression: some attachments, links are disabled in the message body

VERIFIED WONTFIX

Status

MailNews Core
Backend
P1
normal
VERIFIED WONTFIX
17 years ago
9 years ago

People

(Reporter: marina, Assigned: Jean-Francois Ducarroz)

Tracking

({regression})

Trunk
mozilla0.9.3
All
Windows 2000
regression

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
*** observed with 2001-07-10-0.9.2 build ***
i tested it with russian pages(cyrillic Koi8-r, cyrillic-1251), bulgarian pages
( cyrillic-1251), chezk pages ( windows-1252), greek pages ( windows-1253). All
links are removed from those pages after i attach them to the message body. I
don't see it happening with western europeen pages and with ja home page.
(Reporter)

Comment 1

17 years ago
above is the URL to the bulgarian page, i saved it and i can see it fine when
open through Windows Explorer ( same happens with russian, chezk and greek pages)
Summary: Some eastern europeen attachments loose links in the message body → Some eastern europeen attachments loose links in the message body

Comment 2

17 years ago
When I save the attachment to a local file then the links appear again. So looks
like the data is sent correctly but displaying it has a problem.

Comment 3

17 years ago
Is this reproducible with NS6 or NS6.01?
(Reporter)

Comment 4

17 years ago
it is reproducable with PR1 ( 2001-06-07 build)
(Reporter)

Comment 5

17 years ago
compare to 6.0 RTM ( build 11/07/00) this is a regression. None of the links in
saved pages are losr after attaching
Summary: Some eastern europeen attachments loose links in the message body → Regression:some eastern europeen attachments loose links in the message body

Comment 6

17 years ago
Using NS6.01, I can see the links in the attachment. So it was sent correctly 
but viewing has problem.
Cc to jenm, can this be nsBranch? 
This does not happen for "send page" from browser but happens when attaching 
local HTML files. Since the data is not broken if you save the attachment 
locally then you can see the links correctly.
So far, this is only for particular charsets. Can this be reproducible with 8 
bit Latin1 files? Is this Windows only or cross platform?
Keywords: regression
(Reporter)

Comment 7

17 years ago
This is a cross-platform problem, happens to other 8 bit latin-1 files ( but
Latis-1 pages are less impac, though i've seen almost all links missing in
spanish and finnish pages. I didn't notice broken links in french and german pages)
Hardware: PC → All

Comment 8

17 years ago
Created attachment 42008 [details]
mbox contains a message with cnn.com attached

Comment 9

17 years ago
I can reproduce the problem with attaching locally saved cnn.com.
Reassign to putterman.
Assignee: nhotta → putterman
Component: Internationalization → Mail Back End
Summary: Regression:some eastern europeen attachments loose links in the message body → Regression: some attachments, links are disabled in the message body

Comment 10

17 years ago
reassigning to ducarroz. Any ideas on this Jean-Francois? Adding this as a
possible nsbranch bug.
Assignee: putterman → ducarroz
Keywords: nsBranch
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 11

17 years ago
Here is what appends:

When you send the page directly from the net, we know the origin of it (because 
we have the address) and therefore we can add:

Content-Base: "http://www.zone168.com/"
Content-Location: "http://www.zone168.com/"

to the message part's header.

However, if you save first the page to your local hard disk and send the file, 
we don't know anymore where this page come from and we cannot specify a 
Content-Base and Content-Location information into the message. As this 
particular page use relative links without specifying in the HTML itself the 
content-base, we are not able anymore to rebuilt the correct url when viewing 
the page.

If you are viewing the message using 6.01 or event Netscape 4.x, you can see the 
links but if you click on them you will realize that the url is invalid. With 
Netscape 6.1, looks like we are trying to be smarter by "disabling" invalid 
links.

My conclusion is we cannot do anything about that. Sorry, Invalid.

Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 12

17 years ago
so we are basically saving as a plain text?? Then what would be  the purpose of 
saving html files to local disks?
(Assignee)

Comment 13

17 years ago
We are saving as HTML. The problem is that this page doesn't put the base
location as a meta tag in the html source itself.
(Assignee)

Comment 14

17 years ago
You can do the following test:

Open the page into the browser
Save the page into a file
open the file into any browser

The result will be that even if you can see links, you won't be able to browse them!
(Reporter)

Comment 15

17 years ago
 cnn.com site uses rel links and specifies the content but still has a problem?
(Assignee)

Comment 16

17 years ago
reopen
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 17

17 years ago
the links that are not showing up in the cnn page are relative links. Those who
are absolute are showing up!

However, I need to figure out why when you load the attachment into a browser 
window, invalid links are showing up! maybe a css matter...

Comment 18

17 years ago
When this attachment is saved out of the mailbox, do we have the information we
need to set the base at that time?  If so, perhaps we could write a base header
into the document as we're saving it?  (Given your comments on reopening this
bug, this idea would probably have to spin out to another bug if it even makes
any sense.)
(Assignee)

Comment 19

17 years ago
Right, we need to open a new bug about saving the content-base into the saved HTML file to avoid breaking links. 
About this bug, I don't think we can do anything. Wont fix!
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Updated

16 years ago
QA Contact: ji → marina
(Reporter)

Comment 20

16 years ago
Jean-Francois, do we know if such bug was open before i verify this one?
(Assignee)

Comment 21

16 years ago
no idea, personnaly I haven't open a new bug.
(Reporter)

Comment 22

16 years ago
verified as wontfix
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.