2

I have a similar scenario as described in this question (iOS 8.3 fixed HTML element disappears on input focus) but my issue is different. I have a chatbox iframe within a scrollable parent. When the iframe is open, it expands to fill the entire viewport.

<body>
    <!-- PARENT PAGE CONTENT -->

    <div class="webchat-container"> 
        <div class="webchat-header-container">blah blah chat</div>

        <!-- Iframe contains a reply bar with a text input with fixed positioning to the bottom -->
        <iframe src="chatapp"/>     
    </div>
</body>

The .webchat-container has a set of base mobile styles:

.webchat-container {
    width: 100%;
    height: 70px;
    position: fixed;
    bottom: 0;
    z-index: 50;
    transition: height 300ms ease-in-out;
    -webkit-transform: translate3d(0px,0px,0px);
    transform: translate3d(0px,0px,0px);
}

When open, .webchat-container gets this additional style:

.webchat-container.open {
    height: 100%;
}

On focus of the text input in the reply bar, the child iframe uses postMessage() to let the parent know the input has focus, so can I apply some classes specifically for ios devices to deal with the unfortunate way ios handles fixed positioning.

I add a .no-scroll class to the body of the parent:

body.no-scroll {   
    position: fixed !important;
    top: 0;
    bottom: 0; 
}

and a class to the responsive container that holds the iframe:

.webchat-container.ios-positioning.open {    
    position: absolute !important;
    overflow: hidden;
    top: 0 !important;
    bottom: 0 !important;
}

There is a flicker when the input is focused, but other than that, this achieves the desired effect... The softkeyboard slides up and the reply bar is sitting where it should be, just above the keyboard. The chat widget also still correctly fills 100% of the viewport, with no sight of the parent or weird zooming or centering bugs.

And now for the issue....

If I click done to dismiss the keyboard and then focus the input again, the .webchat-container will sometimes become invisible, with only the flashing cursor visible (which is how I know the element is still there and in the correct position). If I inspect the element in Safari, the blue highlighting of the element also shows that it is in the correct place, but just invisible/transparent. The classes are also being applied to and removed from the element correctly.

I have tried dismissing and refocusing the keyboard slowly, fast, irregularly, and sometimes it will repaint correctly and sometimes it wont. It appears to be random. I have also tried forcing repaints by triggering an animation on focus... doesn't work. So I don't even know if this is a lazy repaint issue or not.

The chat app contained within the iframe is React on the front-end and C# & asp.net on the back-end.

If anyone has any idea what could be causing this intermittent element invisibility, and even better, any idea on how to approach solving this, I'd really appreciate it. IOS and its various eccentricities have had pulling my hair out for days, and this is the final problem that I haven't yet been able to solve.

Community
  • 1
  • 1
slinky_bass
  • 95
  • 1
  • 5
  • I've got exactly the same problem with an overlaying div that has an iframe that loads a React app. I'm not sure if this is related to the recent iOS 10.3.x update but I haven't seen this before. Immediately after typing something in an input field, the iframe disappears. Sometimes it takes typing a couple of characters, sometimes the first char makes it disappear. – tukkaj Apr 13 '17 at 09:03
  • @tukkajukka Interestingly enough, in my scenario, when the element DOES display correctly on input focus, I have no issues when typing. The element will remain displaying correctly on typing, I can have loong conversations with the AI, sending multiple messages, and everything remains visible throughout. My particular strain of "random invisibility bug" only seems to hit on focus, when the soft keyboard is activated. It either displays correctly or it's invisible. – slinky_bass Apr 13 '17 at 09:25
  • have you tried hiding the soft keyboard does it affect things? – tukkaj Apr 13 '17 at 09:30
  • @tukkajukka No, I haven't tried that. If the culprit IS the soft keyboard then I'm pretty screwed, as I need the soft keyboard to display so my users can type messages :D I suspect it's an extension of the ios fixed position bug, perhaps combined with lazy repaint bug or something else. I've found one possible approach here https://blog.mobiscroll.com/annoying-ios-safari-input-issues-with-workarounds/ where they nuked the text input and knocked up a div to act as an input. Sounds hacky, and would require a change to the chat app which isn't ideal, but at this point I'm willing to try anything. – slinky_bass Apr 13 '17 at 10:02

1 Answers1

1

This seems to be related to iOS zooming in when an input gets focused.

I managed to fix it by setting position: fixed; to the body element once I open the overlay element (that contains an iframe where the input is). Setting the position to fixed also prevents scrolling underlying elements.

tukkaj
  • 596
  • 1
  • 6
  • 16