Contraction of text entry field not saved when tabs on bottom

[dirksierd]

When opening a new conversation window the input field is a little bit to big (3 pixels maybe). I think this is being caused by the smaller drag handler. This shouldn't be a problem because I can resize this to minimum height and everything 's fine again, but when I close the window and reopen it the setting seems to be reset.

I added a video to visualize my point

[dirksierd]

Inputfield resizing

[jas8522]

I can't reproduce this. I can resize it smaller and it will stay that way even after restarting Adium. Are you sure you weren't reproducing this with an earlier beta? It was fixed for b7...

[jas8522]

Oh nm, I see, it has changed - it's now only a 2 pixel difference rather than about 7 before. Seriously? No offence but I can't see why people care so much over 2 pixels! ;)

[siriusfox]

I'm experiencing the same problem. It isn't a show stopper, but it is visually irritating.

[pianomanjeremy]

I've got the same thing. I use small fonts, so I notice it more. No biggie, but it's definitely a bug. Great work overall, guys! Oh btw, wasn't there gonna be msn personal messages in this version?

[evands]

I can't reproduce this in 1.2b7 using Helvetica 5 point as a (ridiculously small) default. What is your default font in which you're seeing it?

[siriusfox]

This is a font independent bug as far as I can tell. I use Times New Roman 12pt by default.

[evands]

Ah. You have to have the tab bar displayed on the bottom. If it's on the left or right, the bug does not occur.

[dirksierd]

Helvetica 12pt is what I'm using and it's not such a big deal, but like siriusfox told it's a bit visually irritating.

[pianomanjeremy]

Yeah I have the tab bar on the bottom as well. I use Lucida Grande 12.

[evands]

(In [22112]) After the tab view hides or shows (including when the chat window first opens, if the tab view is not set to always show), we need to readjust the size of the text entry view. Fixes #8701

[zee]

This bug appears again in 1.2.2, so this ticket should be reopened.

[evands]

Yeah, the fix had caused way more problems than this minor issue.

[evands]

(In [22662]) Use RBSplitView instead of NSSplitView for the splitview containing the message view and the text entry AIMessageEntryTextView. This allows us to have more reliable control over its subviews' positioning. Fixes #8701.

[evands]

(In [22663]) Merged [22662]: Use RBSplitView instead of NSSplitView for the splitview containing the message view and the text entry AIMessageEntryTextView. This allows us to have more reliable control over its subviews' positioning. Fixes #8701.

[Robby]

This will be in 1.2.3, won't it?

[siriusfox]

I'm running 1.2.3 and this bug is still present. I type some text, hit return, and the box just keeps on growing. Every time I type a message I have to resize the box to keep it from getting to big.

[jas8522]

siriusfox: we really need to figure out how to reproduce this... you didn't mention if you have gone through all of our TroubleshootingTips or not - perhaps one (or more) of them will help.

[evands]

Replying to siriusfox:

I'm running 1.2.3 and this bug is still present. I type some text, hit return, and the box just keeps on growing. Every time I type a message I have to resize the box to keep it from getting to big.

10.4 or 10.5 (not that it should matter, since there's now a single code path for both, but let's see if we can get the same environment for testing)? If you start with the box at the minimum size, type text with multiple lines, then delete the text, does it return to the proper (minimum) size?

[Justine]

When typing a message with multiple lines and deleting, the entry field returns to the normal size, yes.
But when sending a message with multiple lines, the entry field maintains the size of the multiple line message.

[siriusfox]

I'm having the exact same problem. What I can't explain though, is that most of the time sending a multiline message does not return to the default size, but there are a few times when it does. I'll take me a while to see if I can find a correlation, as most of the time it seems random.

[jas8522]

OK this seems to not make much sense, but using the exact same message window with the exact same (meta)contact (only one tab open anyway) I can reproduce this while using Bonjour, Gtalk and AIM but not MSN - With MSN it always snaps back to the default single line height. I have been able to test and confirm this with two different metacontacts now.

[jas8522]

That seems ridiculous because it is... testing with further metacontacts reveals the service doesn't matter (which makes more sense... that was the part I wasn't believing to begin with).

It seems that as long as you send at least one single-line message before sending any multi-line messages it will always snap back to single-line height, but sending a multi-line message right after opening the message window/tab will result in it not snapping back to single-line height.

[Robby]

#9331 is duplicate of this ticket. It's a very detailed report, maybe we can benefit from it.

[boredzo]

I can reproduce this on Mac OS X 10.4.10. Haven't tested on my Leopard machine.

[bobo_italy]

I can reproduce this defect on Mac OS X 10.5.2, MacBook Pro 2.6 Ghz, Adium 1.2.3. I confirm the field resizes correctly when deleting the entered text but doesn't resize when sending the message. Hope you will resolve it soon.

[evands]

(In [22720]) Only update the stored value for the minimum text entry view height when it's being dragged by the user (not when it expands because the text requests that it do so). This fixes the remaining cases in Adium 1.2.3 which could lead to the text entry field not contracting back to the user-requested size after sending a message or pasting text. Fixes #8701

[evands]

(In [22721]) Merged [22720]: Only update the stored value for the minimum text entry view height when it's being dragged by the user (not when it expands because the text requests that it do so). This fixes the remaining cases in Adium 1.2.3 which could lead to the text entry field not contracting back to the user-requested size after sending a message or pasting text. Fixes #8701