Closed Bug 690343 Opened 14 years ago Closed 13 years ago

Clicking the reply button results in a blank compose window that fails to update when you type.

Categories

(Thunderbird :: Message Compose Window, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: IDontUseMozillaAnyMore, Unassigned)

Details

Attachments

(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Build ID: 20110902133214 Steps to reproduce: Clicked the reply button. Actual results: The compose window opened but there was no content displayed. Alt-tabing out to another application and back causes the window to refresh correctly. Typing in the window does not cause it to update it's appearance (ie the new text does not appear in the window. Text delete does not get removed). Alt-tabbing again causes the window to refresh and the edits to be displayed. Expected results: The window should work correctly in the first place. It should display every update as it happens. - Happens in version 5.x, 6.x and 7.x. - Happens on multiple Macs with the same email accounts. - Happens still if I create a new profile and add the email account to it.
Just an extra note, this does not seem to happen every time, but for me it happens for about 1 message in every 3.
Do you have extensions installed in your clean/new profile ? Anything in Tools -> Error console when this happens ?
No, nothing in the error console when it happens. I also cleared out all the extensions and rechecked before reporting. This also happens for another user here. It could be that we have multiple email accounts setup in Thunderbird. (6 different email addresses all based off the same IMAP server).
I have been getting this too, sporadically. Of course, once I started trying to recreate it I can't, so the details are from memory. :( Here are some details that might help narrow it down. I'll add more if I'm able to determine more about the problem. Configuration: - I'm running OS X 10.6.8 with Thunderbird 8.0. This problem only started for me the last month or so; I've been using TB for over 5 years with this account. - I have multiple accounts in the same profile, each of which sends with its own account. - The error console has many instances of the following error, which I can only assume is related: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgFolder.getStringProperty]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/folderPane.js :: getSmartFolderName :: line 2471" data: no] Source File: chrome://messenger/content/folderPane.js Line: 2473 Manifestation of issue: - This error occurs when I open a compose window. It shows only the "from" field selector, and all other fields blank, including the body (I have signatures by default on all my accounts). - If the last message was sent from a different account from the current one, it shows the "from" field for that previous account. - If I click on the window, IIRC it does nothing. But if I move the window just a little bit, the correct information displays. It's as though there were a screenshot of a blank window pasted over top of it. - As best as I can recall, I've gotten this for both new messages and replies. - As best as I can recall, I've gotten this both when using keyboard shortcuts to open new/reply messages, and when clicking the relevant buttons in TB. - I've disabled and enabled all of my add-ons and am still unable to recreate it on demand, but it was happening consistently just before I came to look for the bug on bugzilla. - When trying unsuccessfully to recreate the bug, as I went between accounts opening compose windows, I noticed that the window initially opens with the last-used "from" account, then changes to the active "from" account in a fraction of a second (which is what is supposed to do). I suspect this bug has something to do with a glitch in this particular functionality.
Hi all, Thank you for starting the thread. I believe there are many other separate bug reports in Bugzilla all relating to this same issue and this one most closely matched mine. I too am on a Mac, OSX 10.6.4 to be exact. I have been having this problem on and off since Thunderbird 5.0. As of last week using Thunderbird 8.0 this has become a chronic problem for me. It is now to the point that I can only reply to one email with proper functionality. On any subsequent attempts to reply to emails I will have to Quit Thunderbird completely, re-initiate the program and then once again I am able to reply to one email before I have to repeat the shutdown process again. What I'm experiencing: 0. I use preview mode to interact with my email 1. I click on an email subject to read it. 2. I click on Reply or Reply All as the case may be to respond 3. If this is my first reply since starting Thunderbird, then the email reply template will temporarily appear with a greyed out header (meaning I can't edit any of the fields) after about 10 seconds, the template/form becomes "enabled" for editing. 3a. If I've already replied to an email (any email since starting Thunderbird) when I click on Reply or Reply All, I see the "disabled" reply template. None of the reply form fields are editable. The From/To and Subject fields are greyed out and empty (there is no reference to the senders/recipients or subject of the original email). The body field is completely blank and uneditable. The only reference to the original email is the template header/title: "Write: Re: Original email subject line" I found a thread a few months ago suggesting that I change my format settings to the equivalent of plain text (can't remember the exact recommendation). That seemed to work for some but not for me. I also read a recommendation to disable add-ons so I've been running a naked install of Thunderbird for the last 60 days or so. And still the problem persists. Hoping we can get this sorted. P.S. As I was testing to reproduce the bug and write this comment I went back to one of those blank email reply templates (I click reply all, saw the blank template, came over here to write for about 5 minutes) and found that the edit template (as I'm calling it) had actually loaded and I can now reply as expected. So in essence, there seems to be a very long delay between hitting the reply button and gaining access to the edit email form/template. I'll do some more testing and see if the edit form consistently loads and how long it actually takes. elan e
To confirm both my experience and Ian's: 1.I initiated an email response, 2. Received an uneditable reply form 3. Left the form open on my screen with touching any keys or the mouse for 4 minutes. Nothing happened. 4. After 4 minutes, I clicked into any of the other open windows/programs visible on my screen and then back into the Thunderbird email window Result: the form now appears as enabled/editable. I repeated the steps again with no time delay and the results were the same. It's the clicking into any other application or ALT-Tabbing as Ian describes that seems to unlock the email edit form. As far of frequency of encountering the bug: Once I have completed my first "normal" reply, I still have to use the "click away and back workaround" for every subsequent email reply in a single Thunderbird session. elan
Actually, just testing now I can see that simply moving the reply window a few pixels causes it to start working without going to another app and back. It appears to be a very bad screen refresh problem. In fact switching in and out of TB will force a refresh but the window is then still not fully active. So far moving the window seems to give it focus and make it usable. I will continue to work with it for a while to see how reliable the window move is at getting it working.
Confirmed Ian's test above. Just moving the window does "enable" the reply form for me too. Thank you so much Ian for these workarounds. You can imagine how much time I was wasting in the day, having to shutdown and restart Thunderbird for every email reply.
I've just added a few images showing the state of the window at various times. The first shows the initial state of the window when the problem occurs, notice there's no content to the message body, the recipient list is empty as is the to, cc, etc menu. The second image shows the state of the window after you have command-tabbed out to another application and back. This window has refreshed to show the missing contents but no typing goes into the window. The toolbar is also the wrong colour. The third picture shows the state of the window after you move it a few pixels on the screen. It's fully active and able to respond to typing. It's as if the window does not initially get focus or refresh at all. No amount of clicking on the window will give it focus or make anything appear in it. So far the only work around is to move the window. I'm hoping that the appearance of these windows might at least point to the area of the code that may be causing the problem.
I believe I have found the conditions to recreate this bug! :D 1. Open Thunderbird 2. Compose a message (reply) in a new message window. Don't send yet. 3. In the main message window, select a message--one with an attachment--to display in the preview pane. 4. Click and drag the attachment from the message in the preview pane to the message being composed in the separate window. 5. Send the message. 6. Select a different message in the main message window, click reply (cmd+R) Result: message compose window for the reply displays blank, as described in the various reports.
Do the other reporters agree with comment #12 ?
For me it's much simpler than that. I simply open the app click on a message and hit reply. Result is a window that doesn't work, ie isn't fully drawn, typing doesn't appear. The message is changing with your typing you just can't see it in the window.
Now works works for me in Thunderbird 10
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Agree. I am no longer able to recreate the error by following the steps I laid out in Comment 12.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: