*** 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.
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)
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.
Is this reproducible with NS6 or NS6.01?
it is reproducable with PR1 ( 2001-06-07 build)
compare to 6.0 RTM ( build 11/07/00) this is a regression. None of the links in saved pages are losr after attaching
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?
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)
I can reproduce the problem with attaching locally saved cnn.com. Reassign to putterman.
reassigning to ducarroz. Any ideas on this Jean-Francois? Adding this as a possible nsbranch bug.
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.
so we are basically saving as a plain text?? Then what would be the purpose of saving html files to local disks?
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.
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!
cnn.com site uses rel links and specifies the content but still has a problem?
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...
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.)
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!
Jean-Francois, do we know if such bug was open before i verify this one?
no idea, personnaly I haven't open a new bug.
verified as wontfix