Closed Bug 1284540 Opened 9 years ago Closed 9 years ago

Instructions for attaching image to email signature do not work

Categories

(Thunderbird :: Untriaged, defect)

45 Branch
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: r.green, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36 Steps to reproduce: Followed the instructions at https://support.mozilla.org/en-US/kb/signatures for "Including image files in signatures" Actual results: Signature in new message did not contain image, just a blank box where the image should have been. Expected results: Signature in new message should have contained image.
Workaround: Manually edit the saved HTML file in a text editor. Open the image in a web browser and copy its URL. Replace the relative URL in the HTML file with the URL in the clipboard. Save the file.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Just to be sure: - By writing "just a blank box where the image should have been.", are you referring to the message during composition, or when viewing the received message? The signature's image should appear right after pressing Write and before sending, just like the rest of the signature and either for remote or locale images. - Does the problem occur for local or remote images? - For composing the HTML signature that includes the image, did you compose and save a HTML _file_ first as documented in the article? Afterwards, you need to either copy that file's HTML content (source) to the Signature text field and check "Use HTML", OR use the "Attach the signature from a file instead" to include that file (both will do the same). - In short: what exactly is wrong or confusing in the instructions? In order to have the image stored remotely and not to include it in the signature/message itself (i.e. just use an external URL), you need to uncheck "Attach this image to the message" when including the image during signature composition in Thunderbird. Also note the various options for displaying and allowing/blocking remote content when receiving. From your last comment, you appear to have some issues with the URL that may involve space characters. Maybe you could tell exactly what you edited in order to make things work? I did some tests using nightly and beta versions (not the current version) on Windows following the instructions and everything works as it should. Therefore they may have confused you somewhere, but we’re happy to pinpoint where that is and include your suggestions to change them (or you can do it yourself since Sumo is a public Wiki), unless this turns out to be a bug in Thunderbird of course.
(In reply to Ton from comment #2) > Just to be sure: > - By writing "just a blank box where the image should have been.", are you > referring to the message during composition, or when viewing the received > message? Both. > The signature's image should appear right after pressing Write and > before sending, just like the rest of the signature and either for remote or > locale images. > - Does the problem occur for local or remote images? It's a local image, that's why the URL is relative. The URL couldn't be relative in the first place if it wasn't a local image. > - For composing the HTML signature that includes the image, did you compose > and save a HTML _file_ first as documented in the article? Yes. > Afterwards, you > need to either copy that file's HTML content (source) to the Signature text > field and check "Use HTML", OR use the "Attach the signature from a file > instead" to include that file (both will do the same). Yes, I did that. > - In short: what exactly is wrong or confusing in the instructions? > > In order to have the image stored remotely and not to include it in the > signature/message itself (i.e. just use an external URL), you need to > uncheck "Attach this image to the message" when including the image during > signature composition in Thunderbird. The image is not stored remotely anywhere, so that checkbox needs to be checked. > Also note the various options for > displaying and allowing/blocking remote content when receiving. From your > last comment, you appear to have some issues with the URL that may involve > space characters. Maybe you could tell exactly what you edited in order to > make things work? As I said, the URL was previously stored by Thunderbird as a relative URL in the .html file (relative to the .html file). I changed it to the absolute version of that same URL (i.e. beginning with file:///) and it worked. It was nothing to do with space characters. > I did some tests using nightly and beta versions (not the current version) > on Windows following the instructions and everything works as it should. > Therefore they may have confused you somewhere, but we’re happy to pinpoint > where that is and include your suggestions to change them (or you can do it > yourself since Sumo is a public Wiki), unless this turns out to be a bug in > Thunderbird of course. Did you test with a local image?
(In reply to Robin Green from comment #3) > (In reply to Ton from comment #2) > > It's a local image, that's why the URL is relative. The URL couldn't be > relative in the first place if it wasn't a local image. Yes it can, but that's another story. You just didn't provide enough info, so I asked about all scenarios. > As I said, the URL was previously stored by Thunderbird as a relative URL in > the .html file (relative to the .html file). I changed it to the absolute > version of that same URL (i.e. beginning with file:///) and it worked. It > was nothing to do with space characters. Could you define "previously"? Are you referring to an older TB version? Also, you should not need to add "file:///" since it needs to appear as soon as you select the local image, unless you enter it manually. Plus, (I might be wrong but) I don't think Thunderbird should treat image locations as relative to their HTML file used for composing a signature by default - instead it uses absolute locations, hence it adds "file:///" everywhere when using the Choose File button. It wouldn't make sense to have it poiont to a file without it, even though I see your point of desiring to use a relative image location. > Did you test with a local image? I tested all options, of course. Please note that you filed this bug under the Thunderbird product component, but only mentioned Sumo instructions to be wrong without providing info about what is wrong there. If anything is proven to be wrong regarding TB's behavior, the product component may be right but chances are you are reporting the same issue as in bug 1057139 or found on e.g. http://brian.pontarelli.com/2007/02/26/mozilla-thunderbird-image-in-signature/. You could also have a look at http://kb.mozillazine.org/Signatures_(Thunderbird)#HTML_signature_files and the paragraph below it.
(In reply to Ton from comment #4) > > As I said, the URL was previously stored by Thunderbird as a relative URL in > > the .html file (relative to the .html file). I changed it to the absolute > > version of that same URL (i.e. beginning with file:///) and it worked. It > > was nothing to do with space characters. > > Could you define "previously"? Are you referring to an older TB version? No, by "previously" I meant before I applied the workaround that I described in comment 1, and that I explained again above. > Also, you should not need to add "file:///" I did not manually add file:///. As I already explained in comment 1, I opened the image in my web browser and copied the absolute URL from the web browser address bar. > since it needs to appear as soon > as you select the local image, unless you enter it manually. Plus, (I might > be wrong but) I don't think Thunderbird should treat image locations as > relative to their HTML file used for composing a signature by default - > instead it uses absolute locations, hence it adds "file:///" everywhere when > using the Choose File button. It wouldn't make sense to have it poiont to a > file without it, even though I see your point of desiring to use a relative > image location. > > > Did you test with a local image? > > I tested all options, of course. > > Please note that you filed this bug under the Thunderbird product component, > but only mentioned Sumo instructions to be wrong without providing info > about what is wrong there. If anything is proven to be wrong regarding TB's > behavior, the product component may be right but chances are you are > reporting the same issue as in bug 1057139 It does seem to be the same issue, but that bug was abandoned. Possibly the person who filed that bug was mistaken when they said it used to work. Though that still doesn't explain why it works for you! > or found on e.g. > http://brian.pontarelli.com/2007/02/26/mozilla-thunderbird-image-in- > signature/. You could also have a look at > http://kb.mozillazine.org/Signatures_(Thunderbird)#HTML_signature_files and > the paragraph below it. That page implies that this is not supported, so if that's the case, I guess my workaround should be added to Sumo. I've realised that saving a message as HTML shouldn't really be changed to use absolute URLs because then it would break if the saved message and image were later moved together to a different directory.
Sorry, signatures in TB work, you can attach an image directly or via a HTML document. If some forum/SUMO article is wrong, please bring it to the attention of the responsible owner.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
(In reply to Robin Green from comment #5) > No, by "previously" I meant before I applied the workaround that I described > in comment 1, and that I explained again above. Sorry but I thought you were a bit unclear about what the real issue in the article was, and what you did to make things work compared to what you did before and what exactly the workaround was didn't really clarify that. To cover myself and if it helps, I'm not a native English speaker, but I do see some contradictory statements above. > I did not manually add file:///. As I already explained in comment 1, I > opened the image in my web browser and copied the absolute URL from the web > browser address bar. "Copying the absolute URL from the web browser address bar" didn't clarify the issue even though it may look like users can comprehend, but I can't since I don't think a working relative URL is what you can obtain from an address bar when loading the file, unless you mean a part of the copied absolute URL you see there to be used as a relative one, OR you copied the entire absolute URL including file:/// after all, which is similar to using the button. Therefore I asked what was wrong with the URL included in the signature's HTML file when following the steps, i.e. to mention the exact diff between both URLs in order to pinpoint the issue itself. > It does seem to be the same issue, but that bug was abandoned. Possibly the > person who filed that bug was mistaken when they said it used to work. As long as bugs are still open and have a New or Unconfirmed status, no bug is abandoned and new similar ones should be duped to existing ones, but reporters don't always notice them and aren't really expected to have searched for them beforehand. > Though that still doesn't explain why it works for you! It probably works because I did what is described in the article using the mouse, so images are added as absolute images when using "Choose File", and I'd expect to see the same behavior on Linux. I think the issue is that you entered e.g. "img/foo.jpg" only, without file:/// (hence considered as a web URL, so an error message should follow shortly after) and assuming Thunderbird should allow including relative URLs for images. As you can read on other web places, using relative URLS to define local images appears to be tricky for several types of software, but it's no rocket science. I do admit that the Sumo instruction about what to enter in the text box when adding an image is a bit minimal. Also, the screenshot in the article may be misleading since it only displays the file name, and just entering that doesn't work. It's unclear to me if it ever did, however. > That page implies that this is not supported, so if that's the case, I guess > my workaround should be added to Sumo. I wouldn't consider the workaround described and refering to "manually editing a HTML file and replacing the relative URL" to be suitable since a) there is no reference to any legitimate use of relative URLs for images in the entire KB (other than the image displayed implying so, or that adding e.g. img/ would work), b) there is no relative URL to replace, other than what you probably entered and does not work, and c) using a text editor for fixing something undocumented makes no sense, apart from suggesting there is a bug not yet confirmed. However, adding a note about the requirement to use absolute paths (i.e. use the button) when selecting a local image as well as changing or removing the screenshot may be useful. For a workaround, it may be better to use or document the use of Insert > HTML or an add-on to fix the URL as described in this support question: https://support.mozilla.org/questions/1095467. > I've realised that saving a message > as HTML shouldn't really be changed to use absolute URLs because then it > would break if the saved message and image were later moved together to a > different directory. True, and I'm not saying you are wrong or don't have a point, just that it's probably not supported. Reading the instructions it may look that way, and I just found bug 280783 that may also cover the same issue, so chances are this will never be fixed to include support for adding relative images in some easy and obvious way. I'll leave it for others to decide on whether to dupe any bugs involved, how to treat this one (Sumo or TB related) and suggest additions/changes for the article since some input is needed. Feel free to reply and add info though and please let us know if you agree or disagree with the above.
Resolution: INVALID → FIXED
I suggest you discuss the article on SUMO in it's discussion tab, we have not used Bugzilla for SUMO articles now for years.
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.