I tried changed bar-header from docs/components to bar-footer via codepen with v0.9.27 but it still always shows up as a header. And only after I remove item-input-inset, does it go back down to the footer position, is this a bug or a lack in my understanding of the framework?
<div class="bar bar-footer item-input-inset">
<i class="icon ion-ios7-search placeholder-icon"></i>
<input type="search" placeholder="Search">
<button class="button button-clear">
item-input-inset uses relative positioning; so, it should happily put it wherever bar-footer ends up being. Strange though.
Can you share that CodePen sample?
I just tested on mine as well and got similar results. However, I think I have a fix for it:
<div class="bar bar-footer item-input-inset footer-item-input-insert" ng-if="mc.showSendMsgForm">
<input type="search" placeholder="Message" ng-model="msg.text" maxlength="500">
<button class="button button-clear" ng-hide="mc.hideSend" ng-click="sendMsg()">
foot-item-input-insert class is defined as :
/** For the message bar **/
Try to see if adding that class solves it for you.
My codepen sample: http://codepen.io/pulkitsinghal/pen/whjxe I’m not sure what I did wrong but applying
foot-item-input-insert didn’t help me.
em…you can change the position by using CSS (set position to absolute). however, there may be a terrible problem . if u test ur app on real device, you may find that the keyboard blocks the footer
I also just noticed this in
js/utils/keyboard.js. Android devices hide the footer when the keyboard appears.
Is there are a solution to this? Inputs in the footer are popular in apps for messaging etc, and if not, I will probably be sending a pull request when my app gets to this point
@AshConnell Did you come up with a solution for this? Working on the same thing right now.
Yeah I just used my own footer and made it position fixed.
Drifty are working on an overhaul for keyboard related stuff so they might have a proper solution in the pipeline
Cool, thanks for the wisdom.