GitHub Issue | n/a |
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Won't Do |
Resolution Date | 2020-01-09T23:25:01.000+0000 |
Affected Version/s | Release 1.7.2, Release 1.8.0, Release 3.2.0, Release 3.2.1 |
Fix Version/s | Sprint 2011-37, Release 1.8.0 |
Components | iOS |
Labels | branch-5062, module_tableview, qe-3.2.1, qe-testadded |
Reporter | Dawson Toth |
Assignee | Eric Merriman |
Created | 2011-09-18T09:28:48.000+0000 |
Updated | 2020-01-10T10:30:37.000+0000 |
Problem
A table view with a text field doesn't size properly to account for the keyboard in portrait orientation. This will be easier to see in practice, so please take a look at the example.
Example
Perform the following steps:
1. Drop the following code in an app.js, and run it in the iPad simulator.
2. The app automatically focuses the last text field in the table view, popping up the keyboard.
3. Verify that you can see the text field, and everything looks as it should.
4. Now scroll to the top of the table view.
5. Try to scroll back down so the last text field is visible. The height of the table view is such that you cannot keep the text field on screen.
var win = Ti.UI.createWindow({ title: 'Focus Test', backgroundColor: '#fff' });
var rows = [];
for (var i = 0; i < 20; i++) {
var row = Ti.UI.createTableViewRow({
height: 40
});
row.add(row.textField = Titanium.UI.createTextField({
value: 'Last row focused; Scroll up, and then try to scroll back down.',
color: '#000',
top: 5, right: 10, bottom: 5, left: 10,
borderStyle: Titanium.UI.INPUT_BORDERSTYLE_ROUNDED
}));
rows.push(row);
}
win.add(Ti.UI.createTableView({
data: rows
}));
win.addEventListener('open', function() {
rows[rows.length - 1].textField.focus();
});
win.open();
Note that I commented on the commit for this: {quote} This doesn't account for when the keyboard is invisible, such as when you have a bluetooth keyboard (or barcode scanner) attached. If you focus the top text field in my example on TOMOB-5301, connect a wireless keyboard, and focus it, the text field will scroll off the top of the screen. {quote} https://github.com/appcelerator/titanium_mobile/commit/a735e00b819b1cb365c24c0a923a997127abf173#commitcomment-599644
An additional change, pull request #479 has been pulled into master, and merged into branch-5062 to address this additional test case.
Almost. Still not solved, though. I'm sorry I don't have a better repro case than the client's app, and can't figure out why it only occurs on my iPad and not Stephen's. I'm working on it. I have been investigating, though. Your fix above doesn't work for me because handleNewKeyboardStatus is getting called through didKeyboardFocusOnProxy on TiRootViewController. In this case, your keyboardVisible check in TiUITableView.m won't prevent the resize. But even without that check, it shouldn't scroll a clearly visible component off the screen. Right? Take a look in TiUIView.m. In the OffsetScrollViewForRect method, obscuredHeight line 65 will be the full height, 1004. 0+1004-0=1004. This doesn't sync up with comment 66, but does with comment 70 (these two stand in contention with each other -- might want to revisit those). Now look at line 76: scrollVisibleRect.size.height -= obscuredHeight means the scrollVisibleRect.size.height will be 0. Combined with line 87, it makes sense why the text field is scrolled to the top. What I don't get is why others aren't seeing this. And this could plausibly be intended functionality...
Neither I nor Natalie have been able to reproduce this during testing and validation.
If it's OK with you, you can assign to me, that way the pressure is on me to come up with repro steps / conditions. Once I figure it out, or figure out what I'm doing differently / wrong, I'll kick it back to you for fixing, or put it back in resolved.
Reassigned to Dawson to reproduce as he's the only one seeing this problem at the moment.
Possible Apple bug. I checked recent results on openradar and this popped up: http://openradar.appspot.com/8774431 Filed against 4.2.1/iPad only. Nobody with iPad iOS 4.3.5 (myself, Dawson after an update) can reproduce this in Titanium, but the test app provided with the openradar still fails according to the test criteria.
I am no longer able to reproduce this.
Bug fixed. Verified on: SDK: 1.8.0.1.v20111209102124 Studio: 1.0.7.201112080131 OS: OS X Lion Devices Tested: iPad Simulator 4.3, iPad 4.3 Note: Able to reproduce bug in 1.7.5.
Reopening ticket. Was able to reproduce the issue i.e. the last textfield does not appear above the keyboard after you scroll back down: *This is not a regression as this occurred in 3.2.0.GA* Appcelerator Studio, build: 3.2.1.201401281409 SDK build: 3.2.0.GA, 3.2.1.v20140128171647 CLI: 3.2.1-beta3 Alloy: 1.3.1-beta4 Xcode: 5.0.2 Devices: ipad 3 (6.0.1), ipad 2 (7.0.4)
This issue is out of date with our current supported SDK release (7.5.2.GA as of the date of closure), and out of date with mobile OS versions. If community members feel that the issue is still valid, please create a new ticket. Please reference this closed ticket number, include SDK used, comments, and code that demonstrates/reproduces the issue.
Closing ticket as it marked as
Won't Do
.