671530 - New message, Reply or Forward leaves address and subject fields in disabled state

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Marcus von Cube]

Attachment: prefs.js - my current configuration

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

On my iMac (OS X 10.6.8) I select a message, open it and hit the "reply", "reply to all" or the "forward" button.


Actual results:

The message compose window pops up with address fields and subject line filled in but disabled (not editable, grayed out). The message itself is editable. Hitting the button again creates a new window with the fields enabled. 


Expected results:

The address and subject fields should be editable.

Comment 1

[Marcus von Cube]

I've changed the subject to reflect my latest findings: Even opening a new message window with cmd+N opens the first window with address and subject disabled. I have to open another window on top of the bad one to compose a message.

Comment 2

[Ludovic Hirlimann [:Usul]]

Does this happens in -safe-mode too (see http://support.mozillamessaging.com/en-US/kb/Safe-Mode) ?

Comment 3

[Louis Chev]

Running Mac 10.6.8. I removed the Thunderbird 5.0 app, the profile folder and the preferences file, and downloaded a new Thunderbird 5 app. After ISP setup, the same problem occurred immediately.

Comment 4

[Marcus von Cube]

Sorry for not responding ealier. I had to go back to 3.1.11 and cannot test at the moment.

Comment 5

[Marcus von Cube]

The issue seems to be fixed in 6.0

Comment 6

[Marcus von Cube]

Attachment: The screen shot sows a message window with disabled address input field in TB 6.0.

Comment 7

[Marcus von Cube]

Sorry to disappoint you but the bug is still there in TB 6.0. I've added a screen shot.

Comment 8

[Wayne Mery (:wsmwk)]

Are you using OSX address book?

Comment 9

[Louis Chev]

Changing
layers.acceleration.disabled
to true in about:config cured it in my installation of Thunderbird 6.0.1.

Comment 10

[Marcus von Cube]

To Wayne: No, I'm using the TB address book.
To Louis: Thanks, that's worth a try.

Comment 11

[Marcus von Cube]

(In reply to Louis Chev from comment #9)
> Changing
> layers.acceleration.disabled
> to true in about:config cured it in my installation of Thunderbird 6.0.1.

Sorry, I have the same issue still with 6.0.2 on MacOS X 10.6. :-(

Comment 12

[Wayne Mery (:wsmwk)]

I believe this will be a duplicate of Bug 668552

Comment 13

[Marcus von Cube]

The bug is still present in 8.0 so it can't be a duplicate of bug 668552.

Comment 14

[Wayne Mery (:wsmwk)]

Please test with tbird started in safe mode and post results

Comment 15

[Ludovic Hirlimann [:Usul]]

(In reply to Wayne Mery (:wsmwk) from comment #14)
> Please test with tbird started in safe mode and post results

Marcus ?

Comment 16

[Thomas D. (:thomas8)]

Wayne, what's the way forward here?

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to Thomas D. from comment #16)
> Wayne, what's the way forward here?

I think the best way forward is to know whether Marcus can reproduce in safe mode with version 12 or newer. Someone could test the profile, but I judge the odds aren't great that it will fail - because we don't ahve the entire profile

Comment 18

[Jonathan Protzenko [:protz]]

I'm also hitting on Linux now. This is a real pain. Markus, are you running with send in background enabled? The problem happened after:
- sending a message in background
- getting a "the message could not be copied to sent folder, retry?" error
- hitting retry a couple times
- hitting cancel

Comment 19

[Jonathan Protzenko [:protz]]

Actually, this is 100% reproducible and always happens on the same email.

Here's the relevant error message:

Error: TypeError: names.value[name] is null
Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 3058

Comment 20

[Marcus von Cube]

Sorry for not having responded to the "safe mode" query. I must have missed the message. Now back to topic:

Even in TB 12 the problem persists. I hit reply or new (cmd n) and I get a window with the input fields disabled. I do the same again and the new window is operational. Strange.

I didn't do any special setup steps. I'm pretty sure you will get this on a fresh install.

How do I get into safe mode on Mac OS?

Comment 21

[Marcus von Cube]

I looks like the problem depends on whether there is another (broken) message window open or not. The next windows seems to be ok. If I close the broken one before I retry, the problem occurs again. This time I used cmd-E to edit an old message. The command which opens the message compose window doesn't seem to matter.

Comment 22

[Jim Porter (:squib)]

Attachment: Fix this

This bit me too, so I'm going to fix it. The problem occurs when an email address in the message is of the form "[e-mail]" (i.e. no display name). I tried to write a Mozmill test, but for some reason, it works in Mozmill, even without the patch.

Comment 23

[Jim Porter (:squib)]

Comment on attachment 625883 [details] [diff] [review]
Fix this

Clearing out review, since this should probably get fixed by bug 756971. (This may be fixing something different from what comment 0 saw, anyway.)

Comment 24

[Marcus von Cube]

Jim, the problem even occurs in a virgin message window so I doubt it has something to do with a address format.

Comment 25

[Marcus von Cube]

I started /Applications/Thunderbird.app/Contents/MacOS/thunderbird -safe-mode which seems to cure the problem. Starting TB with a fresh profile seems to help either but I'm not willing to recreate my profile (way too much work).

I will check If I can find an extension that causes the trouble and report back here.

Comment 26

[Marcus von Cube]

I think I found it: I've a patched version of the "Buttons! 0.5.3.2" plug-in which seems to cause the trouble. I agree that using a patched plug-in isn't the best idea and calls for trouble but it might still be worthwhile to find out what happens here. I'll attach a copy.

Comment 27

[Marcus von Cube]

Attachment: Buttons! extension, patched to work with TB 12.

This extension may be the cause of the trouble. I like the navigation and citation buttons and would love to see it operational again.

Comment 28

[Marcus von Cube]

The "Real Prev/Next" buttons extension seems to serve my needs.

Comment 29

[Ludovic Hirlimann [:Usul]]

Is this a duplicate of bug 756971 ?

Comment 30

[Wayne Mery (:wsmwk)]

(In reply to Ludovic Hirlimann [:Usul] from comment #29)
> Is this a duplicate of bug 756971 ?

I'm thinking not - 756971 is a trunk regression. But if 756971 fixes this for Marcus, then 671530 should be closed fixed?

Comment 31

[Jim Porter (:squib)]

(In reply to Marcus von Cube from comment #27)
> Created attachment 629610 [details]
> Buttons! extension, patched to work with TB 12.
> 
> This extension may be the cause of the trouble. I like the navigation and
> citation buttons and would love to see it operational again.

If you disable this extension, do things work ok for you?

Comment 32

[Marcus von Cube]

It looks like this was the cause of the problem.

Comment 33

[Ludovic Hirlimann [:Usul]]

Jim shall we close ?

Comment 34

[Thomas D. (:thomas8)]

I've just reproducibly seen this while writing my forthcoming patch for Bug 425451.

This bug depends on setting for recycling the compose window:
- Bug occurs when mail.compose.max_recycled_windows=1.
- Bug does NOT occur when mail.compose.max_recycled_windows=0

- Bug only occurs for replies, never for New Message, Forward Inline, or Edit as New
- Bug usually occurs after this STR:

1 Reply to selected msg in 3pane
2 close reply window
3 Reply to same selected msg in 3pane

Keeping 1st reply window open, then opening another reply window usually works correctly - so even for reply, it sometimes works.

My patch touches the rows attribute of addressingWidget, which may or may not trigger this, but the problem can't be in my patch because it only intermittently fails for reply but always works for all other types of composing new message as laid out above.

Comment 35

[Thomas D. (:thomas8)]

Aceman, you were touching related code in
Bug 431217 - Send button should be disabled until we have a recipient

Any insights about this bug? Conditions and tentative STR in comment 34.
I'm affected by this bug because it busts up my patch of bug 425451, attachment 765576 [details] [diff] [review], which

* for mail.compose.max_recycled_windows=1:
- always works flawlessly for all other types of composing
- even sometimes works for reply
- but intermittently (every second window or so) fails for Reply -> addressing widget and (sometimes) Send button permanently disabled, everything else including my patch behaviour still correct.

* for mail.compose.max_recycled_windows=0
- always works for any type of composing

So I think it's clear there's a problem in the recycled-composition code for Reply. Any chance of tracking that problem down?

Comment 36

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #35)
> Aceman, you were touching related code in
> Bug 431217 - Send button should be disabled until we have a recipient
> 
> Any insights about this bug? Conditions and tentative STR in comment 34.
> I'm affected by this bug because it busts up my patch of bug 425451,
> attachment 765576 [details] [diff] [review], which

Update: I'm also seeing this bug on the same build (24.0a1 (2013-06-17) WinXP) *without* my patch, so it looks as if that's entirely unrelated to my patch.

Which, if true, makes this a major problem because every other Reply on the unaltered build is now showing disabled recipients and user is not able to send the message.

Setting flag to get this on the radar, sorry if it's the wrong flag just remove it.

Comment 37

[:aceman]

Thomas, please first make sure that your problem is not the recent bug 881588. Only when that one is fixed and you still see the problem mentioned here then we should look at this.