Adium

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#8701 closed defect (fixed)

Contraction of text entry field not saved when tabs on bottom

Reported by: dirksierd Owned by:
Milestone: Adium 1.2.4 Component: Message View
Version: Severity: minor
Keywords: input field text entry message window smaller Cc:
Patch Status:

Description

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

Attachments (1)

adium_window.mov (850.7 KB) - added by dirksierd 12 years ago.
Inputfield resizing

Download all attachments as: .zip

Change History (29)

Changed 12 years ago by dirksierd

Attachment: adium_window.mov added

Inputfield resizing

comment:1 Changed 12 years ago by Jordan

Milestone: Needs feedback from users
pending: 01

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...

comment:2 Changed 12 years ago by Jordan

Milestone: Needs feedback from usersAdium X 1.2
pending: 10

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! ;)

comment:3 Changed 12 years ago by Luke

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

comment:4 Changed 12 years ago by Jeremy

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?

comment:5 Changed 12 years ago by Evan Schoenberg

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?

comment:6 Changed 12 years ago by Luke

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

comment:7 Changed 12 years ago by Evan Schoenberg

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.

comment:8 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by Jeremy

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

comment:10 Changed 12 years ago by Jordan

Keywords: input field text entry message window smaller added; inputfield resize removed
Summary: Inputfield too big and resize doesn't get savedContraction of text entry field not saved when tabs on bottom

comment:11 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: newclosed

(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

comment:12 Changed 12 years ago by zee@technocore.ru

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

comment:13 Changed 12 years ago by Evan Schoenberg

Milestone: Adium X 1.2Adium X 1.2.4
Resolution: fixed
Severity: normalminor
Status: closedreopened

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

comment:14 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: reopenedclosed

(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.

comment:15 Changed 12 years ago by Evan Schoenberg

(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.

comment:16 Changed 12 years ago by Robert

Milestone: Adium X 1.2.5Adium X 1.2.3

This will be in 1.2.3, won't it?

comment:17 Changed 12 years ago by Luke

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.

comment:18 Changed 12 years ago by Jordan

Milestone: Adium X 1.2.3Known problems which need steps to reproduce
Resolution: fixed
Status: closedreopened
Version: 1.2b71.2.3

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.

comment:19 in reply to:  17 Changed 12 years ago by Evan Schoenberg

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?

comment:20 Changed 12 years ago by 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.

comment:21 Changed 12 years ago by Luke

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.

comment:22 Changed 12 years ago by Jordan

Milestone: Known problems which need steps to reproduceAdium X 1.2.4

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.

comment:23 Changed 12 years ago by Jordan

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.

comment:24 Changed 12 years ago by Robert

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

comment:25 Changed 12 years ago by Peter Hosey

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

comment:26 Changed 12 years ago by Andrea

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.

comment:27 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: reopenedclosed

(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

comment:28 Changed 12 years ago by Evan Schoenberg

(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

Note: See TracTickets for help on using tickets.