Closed Bug 353205 Opened 18 years ago Closed 13 years ago

request way to set default to no alternate text for inserting images

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement
Not set
normal

Tracking

(thunderbird7 fixed, thunderbird8 fixed)

RESOLVED FIXED
Thunderbird 9.0
Tracking Status
thunderbird7 --- fixed
thunderbird8 --- fixed

People

(Reporter: turningoff, Assigned: protz)

References

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

Currently if you want to insert an image, you have to mouse down and click on don't use alternate text.  I've probably had to do this hundreds of times.  I asked in the forum about was there a way to set this as the default and all I got was nasty flack from someone carrying on about how I disliked blind people and what I wanted violated some standard.

All I'm saying is, leave the initial default to requiring alternate text if you want, but have a way for the rest of us to once only set the default to no alternate text.


Reproducible: Always
I think the preset defaults should be able to be customized, but also be able to toggled within the Insert | Image dialog.
See extension at http://journal.mozdev.org/mailtweak.html 
Looks like a dupe of bug 200620 (wontfixed by a composer peer). Personally I wouldn't mind having a default like [image]...
No, it's not a dupe of bug 200620: having a default value is evil blind-people-hating; making it possible for people who will never provide an alt value to do so automatically is not.

There are four possible states for alt: a real value (which a screen reader will read), an empty value (alt="" means "this is purely visual, don't bother telling someone using a screen reader that spacer.gif is here at all"), no attribute at all  (correct when it's not possible to have one, like an automatically generated page from a directory listing, and better than any other choice when you just aren't going to provide one, so a screen reader will do what it does by default, like read the filename in case that turns out to be useful), and a bogus default value (which makes a screen reader user guess at whether you meant "an image which illustrates the concept of 'image'" or "an image to which I gave a totally bogus alt").

Bug 200620 was wontfix because it asked for the fourth, and (in the third comment) thought that doing so was better than the second, when in fact it's much worse. 
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Message Compose Window
Ever confirmed: true
OS: Windows XP → All
QA Contact: front-end → message-compose
Hardware: PC → All
Version: unspecified → Trunk
If anyone decides to address this, please be aware that besides the Insert..image
dialog, The image properties box (double click image in compose) also brings up the alt text request. Unfortunately, thats the only way to get into advanced editor to add or change inline styles. Because of it's quirky behavior, this usually requires multiple tries, each time requiring a "don't use alt text" click.

For anybody that uses images in mail/news this is a biggy on the wanted list.
Especially for newsgroups. If you are doing advanced composition, this amounts to many, many unwanted clicks.
For Thunderbird 3 to succeed I think we must get away from the traditional taboos.
Flags: wanted-thunderbird3.0a1?
If we want do do this we need to decide which way to go. Since not everybody necessarily reads the html version, and spacer images and such shouldn't be too common in mails, I think /some/ non empty value is in order.

Or maybe simply some pref that power users can set to what their most common use case.
I'm assuming the "insert image" ui is common code with the suite's composer.
Hence references to web pages in bug 200620.
A hidden pref would be fine, or even if the choice to "Don't use alternate text" would persist throughout the editing session, or better, throughout the TB session.

If the UI window is specific to thunderbird, then a third choice of "Remember my selection" would be ideal.

Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.
Flags: wanted-thunderbird3.0a1? → wanted-thunderbird3.0a2?
Flags: wanted-thunderbird3.0a2? → wanted-thunderbird3?
Not a focus for TB 3 at the moment so setting wanted-. We would consider accepting patches if anyone wanted to do them.
Flags: wanted-thunderbird3? → wanted-thunderbird3-
I would support not forcing people to insert an alternate text.  Purely based on the assumption that most people including an image in an email do not understand the effects of the alternate text.  (psst, you really want this if you're mailing an image to a blind person...)  An editor for the web has different requirements, you are more likely to _not know_ who could read that web page.  With email you are more likely _to know_ who is going to read your mail.  You can argue that we want to promote good "standards" but if we just force people to enter something for no good reason then they'll just enter anything.  That reality isn't a good "standard" it's just filler and we made the situation worse overall.

Perhaps having the alternate text assume nothing means alt="" (purely visual) and then choice of "( ) Don't use alt" actually not include the alt attribute would work, but I can understand that's not the same thing.  Maybe just removing the dialog requirement.

Either way this isn't likely to get traction without someone out there making patches as it's not getting on the tb block list.
I hope someone makes a patch for it, because it is really annoying. I just want to insert the picture/send it and be done with it.
Sounds like possible student-project-fodder...
Keywords: student-project
I tested this out and it works well for me.  However let me know if this is the wrong way to go.

This would change our behavior from one of strict compliance to suggestion of strict compliance.  I agree with what the strict compliance is doing, however I think human behavior here is going to create bad alt text instead of stopping to take the time and create decent alt text.  I would think that nothing at all is better that "lkjdlksjd" for an alt text.

For those who understand the alt text they should know better and keep setting them.  This patch keeps whatever is the last chosen option as the default for the next time.  There is a scenario this opens up where not setting the alt text once means the user will not be reminded again until they set an alt text for an image.  I'm of the mind that people either are doing the right thing and setting the alt text every time or not caring and not setting it anytime; I would assume there are far fewer in the middle ground.  This patch plays to that behavior.

I'm pretty sure I need an s/r here but I have no idea who to ask for that.  Also there's no strings here so we can wait until wed when the dust settles.
Assignee: nobody → clarkbw
Status: NEW → ASSIGNED
Attachment #403441 - Flags: review?(philringnalda)
Comment on attachment 403441 [details] [diff] [review]
adds persist="selected" to both radio items

Certainly not that way, since that would do it to SeaMonkey's Composer, too, where it's very much not wanted.

We overlay that, with mail/components/compose/content/editorOverlay.xul, but we need to track down Neil and ask him whether there's a reason that there's not a single persist="selected" in the tree.
Attachment #403441 - Flags: review?(philringnalda) → review-
(In reply to comment #3)
> There are four possible states for alt: [...] no
> attribute at all

Actually, that option constitutes invalid HTML.
Typo, you meant to say "invalid HTML4."
It's not "making it possible for people who will never provide an
alt value to do so automatically"... it's Forcing everyone to 'sign off' that yes, they want to intentionally send an email with a graphic that has no alt text every time they do so... why have "Don't use" anyway, click a checkbox or type an "x" in the box, practically the same effort (not), practically the same result.  Forcing repeated sign off on (no alt text) -is- tediously evil. There is no explicit or implied hate of blind people in private email with graphics. If you re-use programming components among products, use public posting detection if you want to force public forum conformance. Since I've posted a duplicate bug report... is this or is this not 'on the block' for consideration for change of future Thunderbird? MailTweak does not yet work for me with TB3, and is overburden for one small tweak, which is all I want... the freedom to use TB to send pix without constantly signing off that there are blind people (and retro-text people and security reasons) in the world. Perceive this as bitter diatribe if you want, but it is a valid criticism of a -tedious- forced behavior of -no- use to those who don't email to the blind, the textual or the overly secure... which is probably the majority of TB users.
Currently, for EVERY image I want to put a 1 pixel border around (up to 50 per day), I have to also click on "Don't use alternate text". In TB2, I could make this the default, however, on TB3, this option no longer exists.

I do not care if it is not compliant with HTML4 - everyone at my workplace uses Thunderbird or Outlook. Gone are the days when people were using email clients that struggled with showing HTML content.

Please fix this ASAP.
Assignee: clarkbw → nobody
Whiteboard: [has working patch, needs motivation]
Removing student-project because this bug is controversial. I'd like to better understand the use cases (and workflow) for where folks are adding images to emails many times per day.
Keywords: student-project
I started jumping on Gmail every time I wish to send email with inline images.  It's just so much faster than the tediousness of TB because:

1. Gmail can select multiple images in the file select dialog by using the ctrl-click function. TB cannot.

2. In TB I'm forced to click an extra radio button declining "alt-text" for *every*, *single* image.

Yesterday I sent 12 inline images of my daughter's graduation to my friends and family, then I sent 6 inline images of a house I'm selling, then I sent 8 inline images of a project to my supervisor.

It is archaic and sad that TB does not provide the functionality of multiple image select with fast insertion.
OK thanks. It seems to me there is more pain than necessary happening. Here's an idea:

You know when you write "attached" in an email, and tbird slides in that warning if you don't have an attachment? How about when you inline an image you get a slide in warning that there are images with no alt text? Just like you could send an email with no attachments, so too you could ignore the alt text warning and purposely send such emails to sighted users with html compliant email clients. I would ask that (via a follow up bug maybe) when inline images are forwarded the warning reappear if/as necessary so that the recipients can be freshly considered. Only in the case where it is known that all recipients are sighted, would you want to send with no alt.

Hopefully the warning would be worded in a way to convince users that adding alt text is best. Then provide a nice workflow for doing that.

Thoughts?
In my situation, I use Thunderbird a lot for sending instructional emails on how to configure certain software, around to other members in our workplace. This can sometimes involved me having to put up to 20 images (screenshots) in an email. 

I use Lightscreen to take the screenshots (it saves a screen area I select to the clipboard) and just paste them into Thunderbird - no having to save files and insert them via a menu (one by one). This make it quick. I understand you can also drag images into the message composition window, however this is not on the subject of the problem being presented here.

As most sections of the screen have white space, to show a separation between images, I like to put a border around the image. But for EVERY image I want to put a (1 pixel) border around, I have to also click on "Don't use alternate text". In TB2, alternate text was NOT enabled by default.

What I suggest, is two things:
1) Make it default so that the "don't use alternate text" is enabled. However, if the user goes ahead with this, just place a 'alt=""' in the message source. In actual fact, that is what happened in TB2:
<img src="cid:part1.example@123" alt="" border="1" height="878" width="697">

This is HTML compliant, because the alt tag is there.

2) Have a new button on the formatting toolbar, for instance where the insert (link,table,etc.) options are, for putting a border around an image, without having to go through the image properties window and tabs.

I think the focus should be on doing things with as little menus and mouse clicks as possible.
Simple. I use images a lot in my emails.
Either I send photos/graphics/pix... or I screen-capture images to instruct others... or whatever ...and being online daily, emailing daily... alternate-text became a thorn, a -very- =big= thorn.  

(Except now I have MailTweak... problem 'ameliorated', but I post this for development sanity, and to oppose political (in)correctness. I shouldn't have to seek out a 3rd party solution.)  I didn't know TB was so popular among blind-people... or ...that it HAD to share image-placement code with other products... or ... that TB was using to create HTML pages.

1) Make "don't use alternate text" default.
or
2) Create a 'remember my selection'.

and
3) Show a warning similar to the 'attached' warning... if need be.

A) Cause a non-alternate-texted image to have some valid HTML4 entry, =automatically=, when alternate test is -not- supplied... if that's what you need (HTML4 conformance)
B) Just make it so people who email sighted friends/family some images don't have to perpetually click "don't use alternate text" CHRONICALLY.  What if we forced blind people to wear bells in public?  That is the same as forcing sighted people to whisper "image here, duh, giraffe with a saddle"... when those people do -not- know any blind people and don't post images to public areas (which is probably the majority of TB users).
C) This is illogical... people who don't have a need to communicate with the blind or to post to public areas ...will -not- conform to adding useful text just because you make it tedious to avoid. IF they sent images to blind people... THEY'D LIKELY KNOW THAT ...and adjust their email itself accordingly.  Make it possible to 'remember' or default the "don't use..." AND USE A WARNING SIMILAR TO THE 'ATTACHED' WARNING, if you must. If you code share image-placement with other products than unshare it for TB... or give us some kind of option.  No, I don't want to have to open up 'explorer' and "drag'n'drop".

D) MailTweak provides a method to enter a 'default' alt-text ...so this is all somewhat moot now, for those who use MailTweak.  It's still a lame, forced, tedious, irritant. Develop an "alt-routine" image-placement for TB if you are using this image placement code for other products.

With that, I exit this issue permanently (as long as my MailTweak continues to work).  I actually had to train myself, over significant time, -not- to automatically go to the "don't use alt-text" check box... because MailTweak has taken care of it ...and checking that had become so ingrained, I sometimes still go there.   I was seriously waiting/looking for an alt-email program, until MailTweak obviated the problem. And it was a problem, of TB developers making.
I'm unsubscribed.
Status: ASSIGNED → NEW
Please fix this stupid bug. It's very inconvenient to insert a simple image in the message. I hate all Thunderbird developers EVERY time when I need to add a picture. Very nasty.
Altaveron, I am very aware that behavioral changes in software can be frustrating and upsetting, and indeed, I am sometimes frustrated by such things even in code that I myself write.

There are many ways to deal with these sorts of feelings.  Venting (such as in
comment 69) is one; it's very human, and it's not terribly unusual.   That
said, it is not acceptable Bugzilla behavior: it's _extremely_ demotivating to people who are trying to make the situation better, and it often results in the fix to the problem taking even longer than it otherwise would because volunteer developers generally don't enjoy the abuse.

Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>
for more details about what sorts of things are and are not acceptable in
Bugzilla.
And when I said "comment 69", I actually meant "comment 25".
(In reply to comment #26)
> Altaveron, I am very aware that behavioral changes in software can be
> frustrating and upsetting, and indeed, I am sometimes frustrated by such things
> even in code that I myself write.
> 
> There are many ways to deal with these sorts of feelings.  Venting (such as in
> comment 69) is one; it's very human, and it's not terribly unusual.   That
> said, it is not acceptable Bugzilla behavior: it's _extremely_ demotivating to
> people who are trying to make the situation better, and it often results in the
> fix to the problem taking even longer than it otherwise would because volunteer
> developers generally don't enjoy the abuse.
> 
> Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>
> for more details about what sorts of things are and are not acceptable in
> Bugzilla.

Thanks for your replay, Dan Mosedale. But my message is just the truth. The truth from other the same people too. Why does developers community ignore so old bugs still years?
I don't believe "ignore" really captures what's going on correctly here.  The reality is that there are a variety of reasons that bugs don't get fixed as quickly as we would all like, the most common one being that the developer community isn't nearly as large as we might like.  That said, Bugzilla is intended as a canvas _specifically_ for dealing with individual technical problems, and trying to work through general process issues (like we're doing right now!) only gets in the way of solving the bugs themselves.  This will be my last post to this bug on that subject.
May be it will be reasonable to give the rights to Thunderbird to company with a lot of developers?
Bug? What bug?  LOL!  Today I am dancing in the streets!  

First I want to acknowledge the tirelessly dedicated volunteers who created and support TB.  Bravo!  Excellent program!  I use it every day!!!!

Next, many blessings to RpD for your infinite patience (you are on my candidate list for TB sainthood) and for directing my attention to MailTweak!  

And finally, *HUGE* thanks to Rod Whiteley for creating MailTweak <http://mailtweak.mozdev.org/>!!!!!  You sir, are a champion of the highest order and you have my eternal gratitude for driving a stake through the vampire heart of this annoying default behavior in TB.  Can I buy you a beer?

In gratitude, joy, and love,
Bodhi Goforth
Eugene OR
If a selection is provided in a menu then there should be a way for an individual to set one option as a personal default.  Pure and simple.
I'm sure it isn't new info, but I insert my graphics by dragging from Windows Explorer.  MailTweak doesn't help with that, and my email life would be a lot easier if a default could be saved to not require alternate text.  For those who figured out how to get here and vote and comment it's a significant issue.  I hope 10 votes means something.
Steve Henes
Latest versions of seamonkey composer spawn an error message when 'image properties' is closed without providing 'Alternate text'.
This happens no matter when the image is opened. Composer demands 'alternate text' EACH time the properties are revisited!

I am building web pages with many pictures taken on vacation. There is no valid 'alternate text' for each image!

I drag/drop an image to composer. I then use an AutoScriptWriter script to resize newly added images, make them relative to page location, rather than absolute, and link to the image. The script worked fine in composer for seasmonkey 1 but has been broken by 2 because no matter when I script the selection of the "Don't use alternate text", an error message pops up as soon as the script sends 'enter' and some of the settings are lost.

Please provide a way to set "Don't use alternate text" or allow me to use my script to set it. For some reason, selecting 'Don't use alternate text' does not 'work' from the AutoScriptWriter script.

Currently, I have three alternatives: use obsolete version of seamonkey, use a different html editor, scream and curse.

How about providing an 'about:config' setting that would allow us to set composer to default to 'Don't use Alternate Text'?????
Please Please Please!

SeaMonkey is a beautiful project. I love it and Composer (would like a way to launch composer without the need to launch seamonkey and then press control e)
I appreciate all the hard work that went into creating these projects. 
Please allow the users to have 'flexibility'. 
It was the desire for flexibility that drove you to create the project in the first place!
I drag graphics (basically photos) into Thunderbird regularly, and curse Mozilla every time.  The Microsoft model seems to be to constantly remove useful options that were once available.  One of Mozilla's draws has been the ability to customize the products.  Once you decide that users should not be allowed to do certain things that would make their life easier, you are going down an unfriendly path.  As far as I can tell, Thunderbird is still the most user friendly email client, but I haven't searched for quite a few years now.

As far as the strong emotional and attacking reaction of those with vision impairments are concerned,  this option won't make any difference.  Those of us who don't want to have to enter alternative text, are already not doing it.  We just have to pay for it with an email client that makes us struggle more than should be necessary to send our graphics.
I had looked into making attachment 403441 [details] [diff] [review] work inside just the mail directory but it always seems to lead back to mailnews.

In here we actually overlay the file I originally patched:

mail/components/compose/jar.mn
% overlay chrome://editor/content/EdImageOverlay.xul chrome://messenger/content/messengercompose/mailComposeEditorOverlay.xul

With this file:
mailnews/compose/content/mailComposeEditorOverlay.xul

So I could try making the changed needed in mailComposeEditorOverlay.xul however they would be shared changes as well.  I must be missing something because none of this makes sense to me.

I could copy mailComposeEditorOverlay.xul into a similar mail/ directory and add the changes I want there but that seems excessive.

Anyone have ideas here?
Hello!  It's been 4-1/2 years now, so obviously this bug, errr, excuse me, this "feature" is never going to be fixed.

Can someone out there familiar with the TB code post a hacked version of the current source that fixes this bug?

I'd love to build it, install it, and turn off the "auto update" feature of TBird.

Forever.

That's how much this bug bugs me!
Thanks in advance.
Never mind.  I just saw the ref to the MailTweak TB extension above.  I installed it and it works great!  Yahoo!!  Problem solved.
(In reply to comment #38)
> Never mind.  I just saw the ref to the MailTweak TB extension above.  I
> installed it and it works great!  Yahoo!!  Problem solved.

MailTweak no longer works with Thunderbird 5 so the problem has returned.

I should like to support this bug fix.  

My suggestion is to set the default with Use alternate text selected, and with the word Image pre-filled in the text field.  

Recipients who do not display images get told there is an image and blind users (see early posts) who can't see any image are automatically told there is an image.
Yes I support John-Ha's comments and those of others about fixing this, now that the MailTweak extension no longer works.  This bug should have been fixed years ago.

Also when it is fixed, it should be possible to double click on the image selected to have the image pasted directly into the email ... in other words it should work in Thunderbird like it works in Microsoft Word, which makes inserting images a breeze.

As a temporary workaround, do note that it isn't necessary to precisely align the mouse pointer to fill the "Don't use alternate text" box; you can simply click somewhere along that line horizontally and the text will paste.  Next time you insert text, first select "Don't use alternate text".  As you select it, carefully note the box that only then appears along that line.  Next time you insert an image, just click anywhere within that(imaginary) box and the text will paste.  Try that and you'll see what I mean.
As I mentioned previously, I use Composer to build html files. I didn't make clear that these html files are going on CD's that I am sending to people that went on the same vacation trip I took. 

The purpose is NOT to build a web page, but a photo album. It is NOT going to be posted on the web, for anyone to view. It is to be distributed, on CDs, to friends. The photo album has text describing the events.

Those that say 'force the user to put a text alternative to help the blind' are ignoring the fact that the images are often added only to enhance the text and it is redundant to put text descriptions on the pictures. 

It is WRONG for the software developers to assume their products are to be used for only one purpose and try to force the users to fit their behavior into a particular mold. 

It is GREAT to ALLOW and even ENCOURAGE people to build web pages that are 'handicapped friendly', but it is wrong to FORCE people to spend time doing things that are useless for their application. How many of your products are designed to be friendly to sight impaired users? What is your next step, forcing us to add voice-over for everything?

I did find a work around, of sorts. I used a text editor (notepad+) and a macro to go through a directory listing of my pictures, add html code to give me an html page full of pictures with alt="see text".

I then used composer to add text to explain the pictures, THEN, I go through with an 'auto-hot-key' script and re-size the images (I wanted them all to be the same height, and want to maintain the aspect ration.) This was a real pain to do, before this work around because it kept demanding alt text for every picture. 

Please consider the fact that not all users use composer for the function that you envision. 

You make needless work for those of us that work outside of your box.

PLEASE give us a way to set a default value for the alt text field.
This is ironic - last week I was sending scanned family pictures to my siblings and my blood was boiling on each picture inserted - ahhh!!  I didn't realize I was being punished for some perceived greater good of making my family emails sight-impaired friendly.   Please!

OK, enough complaining.  I think this thread is chock full of ideas to make this program even better for users.   Can somebody either add something really cool, or worse case, just sneak in an edit that deletes the offending social engineering requirement?   Leave it as an option.  If you're a programmer and up to the task, make it even cooler.   But it's 2011 and this seems like something that is not useful to the masses.   Inserting pix in an email and resizing shouldn't require extra steps.  Since Thunderbird is in constant competition with other evolving mail tools, it seems odd to retain nuisances like this.
This adds an extra file so that we don't change what mailnews does. If anyone wants to try this out, make sure you run make chrome in $OBJDIR/mail/components/compose.
Assignee: nobody → jonathan.protzenko
Attachment #403441 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #550561 - Flags: review?(philringnalda)
Sorry, forgot hg qadd
Attachment #550561 - Attachment is obsolete: true
Attachment #550564 - Flags: review?(philringnalda)
Attachment #550561 - Flags: review?(philringnalda)
Comment on attachment 550564 [details] [diff] [review]
Don't step on communicator's toes (missing file)

I tried really hard to convince myself I still know anything about this, but all I did was stare in surprise at the evidence that I once did. comment 14 seems to say we're already overlaying - was I wrong? And did anyone ever get an answer from either Neil about why this would be the only persist="selected" in the tree?
Attachment #550564 - Flags: review?(philringnalda) → review?(bwinton)
- EdImageOverlay.xul is an overlay for EdImageProps.xul
- We already have an overlay on EdImageOverlay.xul but it's in shared code, it's mailComposeEditorOverlay.xul and that file lives in mailnews/
- So I'm adding one more file that overlays EdImageOverlay.xul, hence the name, EdImageOverlayOverlay.xul ;-)

I'm not sure Neil is CC'd on that bug.
Neil, could you give a look at this?
Rather than persisting the selected state on the selection control item elements themselves, we normally persist the value of the selection control. That doesn't really apply in this case as we're not actually making a value selection. (At least one radiogroup in editor does make a value selection, but the editor code still doesn't actually use it in that sense...)

Persisting the selection attributes looks like it should work, although of course as soon as you edit an image with alt text then you will get nagged for the next image without alt text. So it might be worth fixing the case of editing an existing image with alt text specified to be empty too.
Yes! Please!!!!  Thanks!!!!!!!!
protz/neil
Surely a partial fix is better than no fix at for this long standing annoyance.
I don't think a lot of folks would be toggling between images with/without alt text.
(In reply to Joe Sabash from comment #50)
> protz/neil
> Surely a partial fix is better than no fix at for this long standing
> annoyance.
> I don't think a lot of folks would be toggling between images with/without
> alt text.

Yeah, I agree, at least for mail composition windows.
Attachment #550564 - Flags: approval-comm-beta?
Attachment #550564 - Flags: approval-comm-aurora?
Comment on attachment 550564 [details] [diff] [review]
Don't step on communicator's toes (missing file)

Please request approvals only when you have review. (Too late for Gecko 6, which is in comm-beta at the moment as well)
Attachment #550564 - Flags: approval-comm-beta?
Attachment #550564 - Flags: approval-comm-aurora?
Comment on attachment 550564 [details] [diff] [review]
Don't step on communicator's toes (missing file)

Review of attachment 550564 [details] [diff] [review]:
-----------------------------------------------------------------

The EdImageOverlayOverlay name is really kinda funny, but I see how we got there from here.

Aside from the nits below, I'm pretty happy with this patch, and hopefully the commenters who haven't switched to another email client will also appreciate the work you've done.

r=me.

Thanks,
Blake.

::: mail/components/compose/content/EdImageOverlayOverlay.xul
@@ +15,5 @@
> +   - The Original Code is Editor Image Properties Overlay.
> +   -
> +   - The Initial Developer of the Original Code is
> +   - Netscape Communications Corporation.
> +   - Portions created by the Initial Developer are Copyright (C) 1998-2000

I strongly suspect this should be "The Mozilla Foundation", and "Copyright (C) 2011"…

@@ +22,5 @@
> +   - Contributor(s):
> +   -   Pete Collins
> +   -   Brian King
> +   -   Neil Rashbrook <neil@parkwaycc.co.uk> (Separated from EdImageProps.xul)
> +   -

Did these people really contribute to this file, or is it mostly your work?  ;)
Attachment #550564 - Flags: review?(bwinton) → review+
Attachment #550564 - Flags: approval-comm-beta?
Attachment #550564 - Flags: approval-comm-aurora?
http://hg.mozilla.org/comm-central/rev/9cff5fa4ae2b
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [has working patch, needs motivation]
Target Milestone: --- → Thunderbird 9.0
I'm really a bit too lame to understand all this, but I am very annoyed with the automatic requirement to go to the page and ad a character in alt text each time. I don't think that I'm too lame to be able to follow explicit instructions on how to use this patchm abd would sure appreciate guidance here.
Thanks
Steve
Steve,

The bug has been fixed, which means once Thunderbird 9 is out, you won't have to decline inserting alt text every time: Thunderbird will remember your settings so that the next time you don't have to select "insert no alt text". I have requested approval for the fix to be included in Thunderbird 8 and Thunderbird 7.

jonathan
Thanks.  I guess that means there is no way I could insert the text from 550564 into one of my configuration files and get immediate results.
Thanks to all involved in fixing this - I can't wait for next release!

Tim
I am happy for those that use the editor for e-mail. I am unsure that this will help me as I use SeaMonkey's Composer to edit HTML files I use to make 'photo albums' to distribute to friends on CD. 
Will SeaMonkey's Composer be included in the fix?
Thanks.
(In reply to BZ from comment #59)
> I am happy for those that use the editor for e-mail. I am unsure that this
> will help me as I use SeaMonkey's Composer to edit HTML files I use to make
> 'photo albums' to distribute to friends on CD. 
> Will SeaMonkey's Composer be included in the fix?
No. But I've realised that there was a (second!) regression in that dialog, where you can't edit existing images without having to reselect "Don't use alternate text" every time, which I will track in bug 531540.
(In reply to Jonathan Protzenko [:protz] from comment #56)
> Steve,
> 
> Thunderbird will remember your settings so that the next time you don't have to
> select "insert no alt text".

Thank you for fixing this.  

Does TB now also remember any text a user has typed into the Alternate text field? If not, is it too late to ask for that to be done as part of the fix?
Thunderbird will now be easier, faster, more functional, and more user friendly.

I can now use Mozilla to send ten photographs instead of popularizing the giant military contractor Google Corporation and Gmail.

Thank you Jonathan Protzenko and everyone for fixing this !!!
Comment on attachment 550564 [details] [diff] [review]
Don't step on communicator's toes (missing file)

Although the bug is marked as an enhancement, we're treating this a bug fix, and therefore yes, this can land on aurora and beta.
Attachment #550564 - Flags: approval-comm-beta?
Attachment #550564 - Flags: approval-comm-beta+
Attachment #550564 - Flags: approval-comm-aurora?
Attachment #550564 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: