Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-15535] Android: TextArea won't go multiline

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2014-01-10T21:34:20.000+0000
Affected Version/sRelease 3.2.0
Fix Version/s2013 Sprint 22, 2013 Sprint 22 Core, 2014 Sprint 01, 2014 Sprint 01 API, Release 3.2.1, Release 3.3.0
ComponentsAndroid
LabelsSupportTeam, module_textarea, qe-testadded, regression, triage
ReporterDan Tamas
AssigneeHieu Pham
Created2013-10-17T17:33:37.000+0000
Updated2014-01-23T06:12:06.000+0000

Description

The textArea behaves like a textFieled - only one line is displayed and you can scroll the text horizontally instead of going vertically and break the words. I'm attaching the testcase and screenshots (3.1.3.GA and 3.2.X)
var win = Ti.UI.createWindow({
	backgroundColor:'red'
});

var ta = Ti.UI.createTextArea({
	backgroundColor:'yellow',
	top:0,
	width:200,
	height:200,
	value:'A long text that should go on more then one line but it seems it doesn\'t'
});

win.open();

var vl = Ti.UI.createLabel({
	font:{
		fontSize:'20dp'
	},
	color:'#fff',
	top:250,
	text:"Ti SDK "+Ti.version
})

win.add(vl);

win.add(ta);
Thank you.

Attachments

FileDateSize
emu_4.0.2.png2013-10-18T08:37:15.000+00008535
emu_4.2.2.png2013-10-18T08:37:15.000+000011483
genymotion_4.1.1.png2013-10-18T09:03:08.000+000013609
tab.png2013-10-18T08:37:15.000+000042936
textarea_3.1.3.png2013-10-17T17:33:38.000+000019078
textarea_3.2.0.png2013-10-17T17:33:38.000+000013973

Comments

  1. Jamie Buckley 2013-10-18

    Hi Dan, I have just tested this with an Android device running 4.2 and Emulator with 4.0.3, Which device did you use to produce this issue? Are you able to reproduce on the Android Emulator?
  2. Dan Tamas 2013-10-18

    Hi Jamie, here is more info about my environment: Ti SDK 3.2.0.v20131016191202 Ti CLI 3.2.0 devices: HTC One V with 4.0.3 Galaxy Tab 7+ with 3.2 (new screenshot) Emulator 4.0.2 - (new screenshot) Emulator 4.2.2 - (new screenshot) Please be sure you are selecting the sdk to be 3.2.x and in the CLI to select the sdk as well with *ti sdk select 3.2.x*
  3. Dan Tamas 2013-10-18

    Tested in genymotion emulator with 4.1.1 too (shot)
  4. Tim Poulsen 2013-10-18

    I can confirm the issue using: TiSDK 3.2.0.v20131017152001 Ti CLI version 3.2.0 ("bleeding edge" install from GitHub master on 18 October 10:40 EST) Galaxy Nexus running Android 4.2.2 Please make sure you're testing with version 3.2 of the SDK, as textareas render multiline text as expected in 3.1.3 and 3.1.4.
  5. Allen Yeung 2013-10-22

  6. Allen Yeung 2013-10-22

    https://github.com/appcelerator/titanium_mobile/pull/4825
  7. Dan Tamas 2013-10-28

    Any news on this? We need this to be able to push further the android app. Thank you :)
  8. Hieu Pham 2013-10-30

    CR + FR
  9. Samuel Dowse 2013-11-01

    Verified and fixed on: Mac OSX 10.9 Mavericks Titanium Studio, build: 3.2.0.201310312257 Titanium SDK, build: 3.2.0.v20131031141643 CLI:3.2.0 Alloy: 1.2.2 Android Emulators: 2.3.3, 4.0.3, 4.2.2 Android Device, Samsung Galaxy Nexus 4.2.2 Textarea goes over multiple lines successfully. Closing.
  10. Sameeh Harfoush 2013-12-23

    Regression, after installing SDK 3.2 the textarea stopped wrapping its content (for caption and entered text). tested on GalaxyS3 and Sony Xperia P running Android 4.1.2
  11. Allen Yeung 2013-12-23

    [~sameeh.harfoush] Do you have a different test case than the one mentioned above? If so, could you please provide the test case so we can take a look at it? Thanks.
  12. Sameeh Harfoush 2013-12-24

    sure please check the code below...
        Ti.UI.setBackgroundColor('white');
        
        var win = Ti.UI.createWindow({
            backgroundColor : 'white',
            exitOnClose : true,
            fullscreen : false
        });
        
        var textArea = Ti.UI.createTextArea({
            width : Ti.UI.FILL,
            //height : 150,
            returnKeyType : Ti.UI.RETURNKEY_DONE,
            enableReturnKey : false,
            suppressReturn : true,
            maxLength : 299,
            backgroundColor : 'white',
            autocapitalization : Ti.UI.TEXT_AUTOCAPITALIZATION_SENTENCES,
            color : 'black',
            left : 40,
            right : 40,
            hintText : 'this is a long hint that is not wrapping in SDK 2.3 also the max length maxLength attribute does not have anuy effect'
        });
        win.add(textArea);
        
        win.open();
        
  13. Alex Bernier 2014-01-07

    Any update on this? Any app using textarea in any meaningful way is unable to move forward with the Titanium SDK.
  14. Chris Muto 2014-01-07

    ^^^ Seconded. I'm trying to release the android version of my app and this textarea issue is keeping me from being able to release. Can we get at least an update of how long this will take to fix so I can tell my teammates?
  15. Rudolf Cardinal 2014-01-08

    Thirded, so to speak. TextArea no longer multiline with Titanium SDK 3.2.0.GA and Android 4.1.1. Enter key does nothing and text scrolls left/right without wrapping. Major loss of function.
  16. Pete Pallo 2014-01-08

    I'm having the exact same issue. Has this really been known since October and not been fixed yet? It works fine on IOS with the Titanium SDK 3.2.0 GA but Android is a no go. This is this last piece I need to work before I can release on Android. Need this fixed ASAP please! Kind of disappointed and let down right now :(
  17. Rudolf Cardinal 2014-01-08

    Looking at the source: https://github.com/appcelerator/titanium_mobile/blob/master/android/modules/ui/src/java/ti/modules/titanium/ui/widget/TiUIText.java ... the only reference to TYPE_TEXT_FLAG_MULTI_LINE is now to disable it: // current (8 Jan 2014) code public void handleReturnKeyType(int type) { // ... int currentInputType = tv.getInputType(); //FLAG_MULTI_LINE will display enter key, therefore disables our ime options. if (!field && (currentInputType & InputType.TYPE_TEXT_FLAG_MULTI_LINE) != 0) { currentInputType &= ~InputType.TYPE_TEXT_FLAG_MULTI_LINE; } //Set input type caches ime options, so whenever we change ime options, we must reset input type tv.setInputType(currentInputType); // ... } where "field" is a boolean that is true for a TextField and false for a TextArea. So the code appears to be forcing the Android multiline flag off for TextAreas (the opposite of what one might expect). There is no other mention of TYPE_TEXT_FLAG_MULTI_LINE in this GitHub repository apart from in the Label code (android/modules/ui/src/java/ti/modules/titanium/ui/widget/TiUILabel.java). So I think this is part of the problem. The other is that in an older (2012) version, there was this code: // old (2012) code public void processProperties(KrollDict d) { // ... if (d.containsKey(TiC.PROPERTY_KEYBOARD_TYPE) || d.containsKey(TiC.PROPERTY_AUTOCORRECT) || d.containsKey(TiC.PROPERTY_PASSWORD_MASK) || d.co ntainsKey(TiC.PROPERTY_AUTOCAPITALIZATION) || d.containsKey(TiC.PROPERTY_EDITABLE)) { handleKeyboard(d); } else if (!field) { tv.setInputType(InputType.TYPE_TEXT_FLAG_IME_MULTI_LINE); } // ... } public void handleReturnKeyType(int type) if (!field) { tv.setInputType(InputType.TYPE_TEXT_FLAG_IME_MULTI_LINE); } // ... } .. which obviously used to set the TYPE_TEXT_FLAG_IME_MULTI_LINE flag. This code seems to have gone, though there is this: public void handleKeyboard(KrollDict d) { // ... if (!field) { tv.setSingleLine(false); } // ... tv.setInputType(textTypeAndClass); // } The Android reference ( http://developer.android.com/reference/android/widget/TextView.html#setSingleLine(boolean) ) says: - public void setSingleLine (boolean singleLine) ... If true, sets the properties of this field (number of lines, horizontally scrolling, transformation method) to be for a single-line input; if false, restores these to the default conditions. Note that the default conditions are not necessarily those that were in effect prior this method, and you may want to reset these properties to your custom values. - android:singleLine ... Constrains the text to a single horizontally scrolling line instead of letting it wrap onto multiple lines, and advances focus instead of inserting a newline when you press the enter key. The default value is false (multi-line wrapped text mode) for non-editable text, but if you specify any value for inputType, the default is true (single-line input field mode). I wonder if the problem is that tv.setInputType is called AFTER tv.setSingleLine(false) ? The Android docs suggest that the tv.setInputType might make the default single-line input. And then there's some code to disable TYPE_TEXT_FLAG_IME_MULTILINE explicitly. All of this has changed from a previous working version. I'm happy to be proved wrong as to the cause but the bug is a very important one. all the best, Rudolf.
  18. Matthew Watson 2014-01-08

    I am also having the same issue as above. It might be worth mentioning, unless you already know that is. That this issue is not present when building for iOS, not sure about the other platforms as our application is only built for Android and iOS
  19. Ingo Muschenetz 2014-01-08

    Hi All, we are investigating this issue now. If we can come up with a simple fix, we will attempt to get it out ASAP.
  20. Hieu Pham 2014-01-08

  21. Rudolf Cardinal 2014-01-09

  22. Alex Bernier 2014-01-09

    Agree with Rudolf. Developers know TextArea return key can't be customized. That doesn't seem like a bug at all. Multi-line functionality, however, is the main reason a developer chooses to use TextArea. Hieu and Ingo: Hieu's comment doesn't tell us the plan for this ticket. Are we to individually dive into Java and fix this ourselves, or are we going to get multi-line functionality for TextArea back on Android? Perhaps the final solution is allowing both solutions, allowing the developer to choose between: A) A TextArea with multi-line functionality and a carriage return returnKey B) A TextArea without multi-line functionality but with a customizeable returnKey I don't know why option B would be chosen over a TextField, though, which is why Rudolf and I (and probably the rest of the watchers on this ticket) are confused by lack of clarity on resolution for this ticket. 3.2 has Android camera parity functionality I've been waiting months for. I'd love to upgrade to 3.2 and close a slew of bug tickets for our Android users. This ticket is the blocker.
  23. Ingo Muschenetz 2014-01-09

    Hieu's comment is not a resolution, just a developer's note. We're still deciding the best option. Your suggestions are helpful.
  24. Ping Wang 2014-01-10

    PR: https://github.com/appcelerator/titanium_mobile/pull/5202 3_2_X PR: https://github.com/appcelerator/titanium_mobile/pull/5208
  25. Alex Bernier 2014-01-13

    Thank you, Ping, Ingo. I installed [latest 3_2_X](http://builds.appcelerator.com.s3.amazonaws.com/index.html#3_2_X), version 3.2.1.v20140110140111, and textarea wrapping is restored. Super excited! I removed a ton of code to make up for hideCamera not being available on android. Android camera still seems to zoom in when using overlay, but I'll put together a ticket for that.
  26. Rudolf Cardinal 2014-01-13

    My thanks also! And thank you, Alejandro, for the link to pre-release versions; I had created a module to implement the fix, which was clearly unnecessary.
  27. Alex Bernier 2014-01-13

    Np, Rudolf
  28. Lokesh Choudhary 2014-01-17

  29. Paras Mishra 2014-01-21

    Verified the fix , hence closing the issue Environment Used: Device : Google Nexus 7, Android Version: 4.4.2 SDK: 3.3.0.v20140117222449 SDK: 3.2.1.v20140117222448 CLI version : 3.2.1 OS : MAC OSX 10.9 Alloy: 1.3.1-beta2 ACS: 1.0.11 npm:1.3.2 Appcelerator Studio, build: 3.2.1.201401151647 titanium-code-processor: 1.1.0 XCode : 5.0.2
  30. Alex Bernier 2014-01-22

    Ingo and Appcelerator Team, just wanted to thank you for resolving this and for the camera updates for android in 3.2. Our camera experience for android is usable for more devices now, and much improved for the devices it already worked for. There are a couple of lingering things I'll open tickets for (camera zooms in with overlay, and also with overlay it seems to take much worse low light photos than the native camera), but we're in such a better place.
  31. Sameeh Harfoush 2014-01-22

    You are welcome guys and thanks for the prompt support :) Good luck :)

JSON Source