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

[JQM 1.2.0 beta 1] Issue with custom select menus in Safari (iOS 5.1.1, iPad 2 and iPad 3) #4949

Closed
Mitch64 opened this Issue Sep 6, 2012 · 6 comments

Comments

Projects
None yet
6 participants
@Mitch64

Mitch64 commented Sep 6, 2012

I did a little test driving with the brand new JQM 1.2.0 beta 1 and noticed, that in the demos & docs the demos for the the custom select menus did behave a little strange on my iPads, both running with iOS 5.1.1. You can see it for yourself at

http://jquerymobile.com/demos/1.2.0-beta.1/docs/forms/selects/custom.html

When clicking on the first custom select menu (the small list for the shipping method) at first the menu pops up and then after approx. 50 ms jumps to the center of the screen (i.e. is being centered)

I did a little research then and found out that in 1.2.0 alpha 1 the behaviour was correct (no jumping).
You can also test this for yourself at

http://jquerymobile.com/demos/1.2.0-alpha.1/docs/forms/selects/custom.html

I also managed to write a little test program and found out that it's not a problem with the demos but with the custom select menus. Because I had some older (latest) versions of JQM I could make sure that the problematic code came in to the codebase probably after 08/28/2012. After looking a little bit into the JS I suppose that after the opening of the menu JQM erroneously thinks it has to resize and that causes the centering.

This issue only occurs on my iPads running iOS 5.1.1. It does not occur on my 7'' Galaxy Tab running Android 2.3.6, my Samsung Galaxy S III running Android 4.0.4 and not on any of my desktop browsers (FF 15, Chrome 21.0.1180.89, Safari 5.1.7)

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Sep 6, 2012

Contributor

We spotted this yesterday with normal popups too, but only if you navigated in from the docs homepage on an iPad and didn't scroll the page (bizarre). Looking into it now.

Contributor

toddparker commented Sep 6, 2012

We spotted this yesterday with normal popups too, but only if you navigated in from the docs homepage on an iPad and didn't scroll the page (bizarre). Looking into it now.

@ghost ghost assigned gabrielschulhof Sep 6, 2012

@jesperveldhuizen

This comment has been minimized.

Show comment
Hide comment
@jesperveldhuizen

jesperveldhuizen Sep 7, 2012

I can confirm that this problem also occurs on my iPad 1 running on 5.1.1, but not on my Galaxy Tab 2 10.1 (running on android 4.0.4).

jesperveldhuizen commented Sep 7, 2012

I can confirm that this problem also occurs on my iPad 1 running on 5.1.1, but not on my Galaxy Tab 2 10.1 (running on android 4.0.4).

@ninichki

This comment has been minimized.

Show comment
Hide comment
@ninichki

ninichki Sep 7, 2012

I think, its a Problem with "Page Resize Event". Sometimes Popups trigger this event and then the popup will be centered in the middle of the screen.

ninichki commented Sep 7, 2012

I think, its a Problem with "Page Resize Event". Sometimes Popups trigger this event and then the popup will be centered in the middle of the screen.

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 7, 2012

Contributor

I don't understand why the popup triggers a window resize event ...

Contributor

gabrielschulhof commented Sep 7, 2012

I don't understand why the popup triggers a window resize event ...

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 7, 2012

Contributor

I have identified the commit that breaks things: 7a14e15. The problem is, this is a fairly extensive commit, pretty much re-writing the popup's open/close logic.

Contributor

gabrielschulhof commented Sep 7, 2012

I have identified the commit that breaks things: 7a14e15. The problem is, this is a fairly extensive commit, pretty much re-writing the popup's open/close logic.

@johnbender

This comment has been minimized.

Show comment
Hide comment
@johnbender

johnbender Sep 7, 2012

Contributor

We have to take another look at this, I wrote some poor tests for the "historyless" popups and this change breaks them (obviously without failing the tests). The tests are fixed though.

Contributor

johnbender commented Sep 7, 2012

We have to take another look at this, I wrote some poor tests for the "historyless" popups and this change breaks them (obviously without failing the tests). The tests are fixed though.

@johnbender johnbender reopened this Sep 7, 2012

arschmitz added a commit to arschmitz/jquery-mobile that referenced this issue Oct 16, 2012

arschmitz added a commit to arschmitz/jquery-mobile that referenced this issue Oct 16, 2012

Revert "[popup] Perform the visual open only when the nav hook has be…
…en acquired -- Fixes #4949"

This reverts commit 3b40d03.

This change doesn't call _open when history alteration is disabled breaking
popups in ie7 by default and anywhere that $.mobile.popup.prototype.history is used

arschmitz added a commit to arschmitz/jquery-mobile that referenced this issue Oct 16, 2012

Revert "Revert "[popup] Perform the visual open only when the nav hoo…
…k has been acquired -- Fixes #4949""

This reverts commit 7c98460.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment