Testing with a current CVS build, Linux: I have a little webpage called My_Mozilla_FAQ.html and i upload it via ftp to a website now and then. This is part of that page usually: <base href="My_Mozilla_FAQ.html"></head> When i now save the page in composer, that line is modified into this: <base href="file:///home/dark2/RECOVER/dark/pix/My_Mozilla_FAQ.html"></head> Which you might guess is where the file is stored on my local disk. Links and images elsewhere on the page are left as is - they are not broken with filepaths anymore, like they were in bug 121980. I can't see any good reason why Composer should tell "the world" about my PC's internal file structures. So I think the full local file-path in the "base href" is a bug.

Is this also due to nsWebBrowserPersist problems? Cc'ing others.

absolutely! *** This bug has been marked as a duplicate of 122227 ***

yes...that would be a dup, wouldn't it.

Is this really a duplicate? Using build 2002021423, I am seeing Mozilla *inserting* <base href="file://..">, though it wasn't there originally. There are two problems: * That this is a local href (which is perhaps a duplicate of 122227 * That it appears *at all*. I cannot get rid of it even by removing it manually from the HTML. As soon as I save, it reappears. And my build does not make other relative links absolute, so how can it be a duplicate? Please consider reopening this bug, as it can not be verified to be a duplicate.

The complaint in this bug is that the base href is being absolutized. So, yes, this is a duplicate of the bug indicated. The problem in comment 4 is a duplicate of bug 125070.

Creating a new file it adds base href=about:blank. I'm hoping that's the same issue.

reassign in case bugs are later reopened