On 2010-03-22, at 09:20, Henry Minsky wrote: > On Mon, Mar 22, 2010 at 9:08 AM, P T Withington <[email protected]>wrote: > >> On 2010-03-21, at 18:53, Henry Minsky wrote: >> >>>> >>>> 2) I don't understand the change to scrollevent. If an inputtextview is >>>> autosizing, it won't have scrollevents enabled will it? It should only >> be >>>> getting scrollevents if it has a fixed size (and hence would scroll any >> text >>>> that does not fit). >>>> >>> >>> Oh yeah you're right. I need to ensure that when the text changes that >> new >>> text height info is stuffed into the LFC some other way >>> in that case. >>> >> >> Actually, I'm wrong. From LzTextSprite.js line 267: >> >>> // NOTE [2009-04-08 ptw] We always send lineHeight events, even if >>> // scrollevents are not requested. scrollevent should probably be >>> // renamed to spriteevent or something >> >> So, your fix does work -- scrollevent is just poorly named. > > > No, I think you were right the first time, the lineHeight > event specifies the interline spacing, but I need the LFC to get the entire > text content height, > > So I think we also need that code to send 'scrollHeight' events > unconditionally also, to > inform the LFC of the total text height.
Ah. I have to wonder if I was confused when I wrote that then? How could the lineHeight change? Maybe I thought I was addressing the issue you are trying to fix and made the same mistake I just did of confusing lineHeight with text height? Perhaps we need to think about this a bit more. Max made scroll events be off by default because always sending them was a huge overhead, and there are only a few cases where they were actually needed. I could see us getting in the same trouble here. We only need to get back size changes in the case where the element is auto-sizing, so, perhaps the right answer is just to enable scroll-events in that case? Then maybe everything falls out?
