-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Popover] Fix bad positioning on IOS devices #4638
Conversation
@w01fgang we had the same problem, but we fixed it differently, we replaced position fixed with position absolute. Keeping it to position fixed results in uncontrollable animations. I will come back later with more info. |
In short, iOS renders fixed positioned elements as absolute when keyboard opens, but this "transition" from fixed to absolute is weirdly and uncontrollable animated and this results in flickering. For our project, the only good solution was to not use position fixed at all. So, both Popover and RenderToLayer should use position absolute instead of fixed. I will come back next week with a PR with the change I described. |
@igorbt when you will make your PR, please let me know. |
53b828e
to
ea2538e
Compare
Actually I don't know why test fails on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that bug is quite embarrassing on iOS devices!
|
||
describe('Device detection helper', () => { | ||
before(() => { | ||
global.window = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I don't know why test fails on src/utils/withWidth.js, I didn't make any changes there.
Yes, you have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ho, I forgot it, will fix it now.
@@ -0,0 +1,69 @@ | |||
/** | |||
* Returns an object with detected device and browser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we need this all browser device detection code for iOS.
It could be as simple as:
// iOS detection from: http://stackoverflow.com/a/9039885/177710
if (/iPad|iPhone|iPod/.test(userAgent) && !window.MSStream) {
return "iOS";
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if we don't have any crossbrowser bugs in other components, it must be simple.
* layer, which will prevent clicks to the underlying | ||
* elements, and trigger an `onRequestClose('clickAway')` call. | ||
*/ | ||
* If true, the popover will render on top of an invisible |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have some indent issue here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll fix it.
@oliviertassinari please take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are almost there. Sorry for taking so long to review this PR.
It would also be great to rebase it on master and to squash down the commits (28).
@@ -240,7 +242,11 @@ class Popover extends Component { | |||
}; | |||
|
|||
a.right = rect.right || a.left + a.width; | |||
a.bottom = rect.bottom || a.top + a.height; | |||
if (/iPad|iPhone|iPod/.test(window.navigator.userAgent) && !window.MSStream) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still, I would move this logic into it's own module so we can test it 👼 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved out to utils.
826e0fe
to
1838b34
Compare
5b91c3a
to
b3a9c8e
Compare
Yes, it might be, because the PR have been made for 0.14.x version or maybe 0.13.x. |
Sorry for taking so long to review that PR. Thanks for digging into that issue. |
I checked it out. Now fix works only if input field in the focus. |
@@ -240,7 +241,11 @@ class Popover extends Component { | |||
}; | |||
|
|||
a.right = rect.right || a.left + a.width; | |||
a.bottom = rect.bottom || a.top + a.height; | |||
if (isIOS() && document.activeElement.tagName === 'INPUT') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side node, with the next
branch we would be using activeElement
I confirm, it's working great now. I'm gonna add some comments in the source code. Thanks 👍 ! |
@w01fgang, on on 10 Dec 2016 you wrote:
How does the situation looks like now? Is the fix merged to v0.16+ as well, or is it only on versions up to 0.14? Asking because I have a similar problem, not with the Autocomplete, but with an IconMenu popover on iOS devices. I'm using v0.16.7, but I've tested it on 0.20 and the issue is present there as well. |
@stas-lesiuk on IOS before the version 11 CSS rule |
@w01fgang thanks for your help. and unfortunately it seems that independently from the if statement result, there's still a problem with IconMenu Popover position on iOS devices. It looks like that's not the same issue like the initially addressed by you, however I wonder whether you may know the possible solution. |
hey there. Do you have any plans on releasing this? The fix is not in the current v0.20 is it? thanks a lot |
@quorak This PR was merged in Dec 2016! |
yeah, it was merged on Dec 16th . |
Adds a device detection helper, maybe useful for cross-browser compatibility and fixes #3638