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

Beta Safari (OS X) Version 9.1 (11601.5.8.1) and IOS Version/9.0 Mobile/13E5181f Safari/601.1 #8357

Closed
JakeCigar opened this Issue Jan 16, 2016 · 24 comments

Comments

Projects
None yet
10 participants
@JakeCigar

JakeCigar commented Jan 16, 2016

Just an FYI that page changing is broken in these betas. I go to a page, and the browser jumps back from whence I came.

http://plnkr.co/edit/JZdKSf?p=preview is a simple site that skips over a page when going back. The only code is

$(window).on("navigate", function(event, data) {
if (data.state.direction === "back" && data.state.url.match(/second.html$/)) {
$.mobile.navigate("index.html")
return false
}
});

In other, more complex sites
$(":mobile-pagecontainer").pagecontainer("change"…
fails the exact same way,

@JakeCigar

This comment has been minimized.

Show comment
Hide comment
@JakeCigar

JakeCigar Jan 16, 2016

It probably has nothing to do with the javascript, as it happens right away going to the second page.

JakeCigar commented Jan 16, 2016

It probably has nothing to do with the javascript, as it happens right away going to the second page.

@dpolivy

This comment has been minimized.

Show comment
Hide comment
@dpolivy

dpolivy Jan 19, 2016

I am having the same issue with our Cordova app (using jQM) on iOS 9.3 beta 1. As soon as a navigation happens to a page, something happens to trigger jQM to navigate right back to where it came from.

It seems the popstate event in iOS 9.3 is now asynchronous; in prior versions of iOS, the generated popstate is usually stopped at this line. But, with the asynchronous event, it is now falling into this case.

Can someone from the jQM team try and dig in with the latest XCode beta?

dpolivy commented Jan 19, 2016

I am having the same issue with our Cordova app (using jQM) on iOS 9.3 beta 1. As soon as a navigation happens to a page, something happens to trigger jQM to navigate right back to where it came from.

It seems the popstate event in iOS 9.3 is now asynchronous; in prior versions of iOS, the generated popstate is usually stopped at this line. But, with the asynchronous event, it is now falling into this case.

Can someone from the jQM team try and dig in with the latest XCode beta?

@dpolivy

This comment has been minimized.

Show comment
Hide comment
@dpolivy

dpolivy Jan 19, 2016

@arschmitz @gabrielschulhof Any possibility one of you can dig into this? Seems like a major issue to address before the next Safari release goes GA.

dpolivy commented Jan 19, 2016

@arschmitz @gabrielschulhof Any possibility one of you can dig into this? Seems like a major issue to address before the next Safari release goes GA.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Jan 19, 2016

Member

this is something we will be looking into very soon i just marked it as a blocker for release

Member

arschmitz commented Jan 19, 2016

this is something we will be looking into very soon i just marked it as a blocker for release

@arschmitz arschmitz added this to the 1.5.0 milestone Jan 19, 2016

@hodoublesy

This comment has been minimized.

Show comment
Hide comment
@hodoublesy

hodoublesy Jan 19, 2016

Are you going to fix in 1.4.X also?

hodoublesy commented Jan 19, 2016

Are you going to fix in 1.4.X also?

@attewd

This comment has been minimized.

Show comment
Hide comment
@attewd

attewd Feb 2, 2016

Heya, any progress on this? I tested this on iOS 9.3 Beta 2 and the problems persist. I'm in a pretty desperate need to get this working with the exitsting 1.4.5 version (before iOS 9.3 gets released)..and as far as I understand so is every mobile app that uses jqm's change page mechanism..

attewd commented Feb 2, 2016

Heya, any progress on this? I tested this on iOS 9.3 Beta 2 and the problems persist. I'm in a pretty desperate need to get this working with the exitsting 1.4.5 version (before iOS 9.3 gets released)..and as far as I understand so is every mobile app that uses jqm's change page mechanism..

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Feb 2, 2016

Member

I have been looking into this and think i have a workaround for 1.4.5 and solution for 1.5 i will post it here shortly for others to try

Member

arschmitz commented Feb 2, 2016

I have been looking into this and think i have a workaround for 1.4.5 and solution for 1.5 i will post it here shortly for others to try

@attewd

This comment has been minimized.

Show comment
Hide comment
@attewd

attewd Feb 3, 2016

Excellent, can't wait!

attewd commented Feb 3, 2016

Excellent, can't wait!

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Feb 4, 2016

Contributor

Here's WebKit's test to confirm the new behaviour:
https://github.com/WebKit/webkit/blob/master/LayoutTests/fast/loader/stateobjects/popstate-is-asynchronous.html

Which links to this commit:
WebKit/webkit@7c03cad

Which links to this WebKit issue:
https://bugs.webkit.org/show_bug.cgi?id=36202

Which links to a change in the HTML specification:
https://html.spec.whatwg.org/multipage/history.html#traverse-the-history

And that WebKit issue links to another one:
https://bugs.webkit.org/show_bug.cgi?id=153686

So it looks like WebKit erroneously made all popstate events asynchronous. Still the fact that this is based on standards work means we can expect fragment-triggered popstate events to be asynchronous, and other popstate events to be synchronous. We'd need to account for asynchronous popstate events in other browsers, too, eventually.

It would be good if a solution could be engineered to cover all 3 possible implementations:

  • all synchronous popstate events
  • some asynchronous, some synchronous
  • all asynchronous
Contributor

jokeyrhyme commented Feb 4, 2016

Here's WebKit's test to confirm the new behaviour:
https://github.com/WebKit/webkit/blob/master/LayoutTests/fast/loader/stateobjects/popstate-is-asynchronous.html

Which links to this commit:
WebKit/webkit@7c03cad

Which links to this WebKit issue:
https://bugs.webkit.org/show_bug.cgi?id=36202

Which links to a change in the HTML specification:
https://html.spec.whatwg.org/multipage/history.html#traverse-the-history

And that WebKit issue links to another one:
https://bugs.webkit.org/show_bug.cgi?id=153686

So it looks like WebKit erroneously made all popstate events asynchronous. Still the fact that this is based on standards work means we can expect fragment-triggered popstate events to be asynchronous, and other popstate events to be synchronous. We'd need to account for asynchronous popstate events in other browsers, too, eventually.

It would be good if a solution could be engineered to cover all 3 possible implementations:

  • all synchronous popstate events
  • some asynchronous, some synchronous
  • all asynchronous
@BSchwetzel

This comment has been minimized.

Show comment
Hide comment
@BSchwetzel

BSchwetzel Feb 5, 2016

The same issue exists in a JQM-based Phonegap (Build)-App (at least with the $(".mobile-pagecontainer").pagecontainer("change"… call we are using). As of now a relase of iOS 9.3 would break our app because of this. Because there is no "web app" providing its functionality, we couldn't even advise to use a different browser. I really hope there will be a fix/workaround publicly available soon, so we don't have to advise our users to not update iOS..

Thank you very much for looking into this!

BSchwetzel commented Feb 5, 2016

The same issue exists in a JQM-based Phonegap (Build)-App (at least with the $(".mobile-pagecontainer").pagecontainer("change"… call we are using). As of now a relase of iOS 9.3 would break our app because of this. Because there is no "web app" providing its functionality, we couldn't even advise to use a different browser. I really hope there will be a fix/workaround publicly available soon, so we don't have to advise our users to not update iOS..

Thank you very much for looking into this!

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Feb 5, 2016

Contributor

I've not been able to reproduce this issue with Ionic. The sensitivity to this issue seems to be something specific to the way jQM handles the events, that at least one other framework does differently enough to be immune.

Contributor

jokeyrhyme commented Feb 5, 2016

I've not been able to reproduce this issue with Ionic. The sensitivity to this issue seems to be something specific to the way jQM handles the events, that at least one other framework does differently enough to be immune.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Feb 5, 2016

Member

yes i believe this is specific to some old code we have which was implemented for a very old version of ironically iOS (4 ) which had a different bug related to this. Since we no longer support iOS 4 i am working on removing this and will post a backwards compatible patch soon.

Its a pretty complex section of the framework so trying to thoroughly test to make sure to not introduce any bugs with the change.

Member

arschmitz commented Feb 5, 2016

yes i believe this is specific to some old code we have which was implemented for a very old version of ironically iOS (4 ) which had a different bug related to this. Since we no longer support iOS 4 i am working on removing this and will post a backwards compatible patch soon.

Its a pretty complex section of the framework so trying to thoroughly test to make sure to not introduce any bugs with the change.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Feb 6, 2016

Contributor

Depending on the amount of churn, do you think it might be better to outsource the navigation engine to something like https://github.com/unicorn-standard/uniloc ? Even if we keep the same jQM-specific abstractions on top, there might be benefits to moving the underlying implementation to something that is closer to how React and Angular apps handle routes.

Edit: nevermind, I just realised uniloc covers the next layer up from where this problem is occurring.

Contributor

jokeyrhyme commented Feb 6, 2016

Depending on the amount of churn, do you think it might be better to outsource the navigation engine to something like https://github.com/unicorn-standard/uniloc ? Even if we keep the same jQM-specific abstractions on top, there might be benefits to moving the underlying implementation to something that is closer to how React and Angular apps handle routes.

Edit: nevermind, I just realised uniloc covers the next layer up from where this problem is occurring.

@vadimtrifonov

This comment has been minimized.

Show comment
Hide comment
@vadimtrifonov

vadimtrifonov Feb 8, 2016

Any progress on the issue? Maybe someone figured out a workaround?

vadimtrifonov commented Feb 8, 2016

Any progress on the issue? Maybe someone figured out a workaround?

@alessandrodamore

This comment has been minimized.

Show comment
Hide comment

alessandrodamore commented Feb 8, 2016

@stegoma

This comment has been minimized.

Show comment
Hide comment
@stegoma

stegoma Feb 9, 2016

Hey! It seems to be solved on iOS 9.3 Beta 3 released last night.
check it out.

stegoma commented Feb 9, 2016

Hey! It seems to be solved on iOS 9.3 Beta 3 released last night.
check it out.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Feb 9, 2016

Member

indeed if you go to the bug linked above they noticed the regression and fixed

Member

arschmitz commented Feb 9, 2016

indeed if you go to the bug linked above they noticed the regression and fixed

@BSchwetzel

This comment has been minimized.

Show comment
Hide comment
@BSchwetzel

BSchwetzel Feb 9, 2016

I can confirm Beta 3 fixed it for our app.

BSchwetzel commented Feb 9, 2016

I can confirm Beta 3 fixed it for our app.

@stegoma

This comment has been minimized.

Show comment
Hide comment
@stegoma

stegoma Feb 9, 2016

Thanks for your reply. I've also confirmed Beta 3.
I'll be checking behavior of future releases such as Beta 4(?), GM, and CM.

stegoma commented Feb 9, 2016

Thanks for your reply. I've also confirmed Beta 3.
I'll be checking behavior of future releases such as Beta 4(?), GM, and CM.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Feb 9, 2016

Member

ok seems like everyone is confirming this fixed so im going to close this issue. If any one notices anything else please open up a new issue and we will get right on it

Member

arschmitz commented Feb 9, 2016

ok seems like everyone is confirming this fixed so im going to close this issue. If any one notices anything else please open up a new issue and we will get right on it

@arschmitz arschmitz closed this Feb 9, 2016

@dpolivy

This comment has been minimized.

Show comment
Hide comment
@dpolivy

dpolivy Feb 9, 2016

@arschmitz Is it still worth pursuing a change to this code to potentially handle the case in the future?

dpolivy commented Feb 9, 2016

@arschmitz Is it still worth pursuing a change to this code to potentially handle the case in the future?

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Feb 9, 2016

Member

the changes i mentioned are things slated for 1.6 regardless of this change so yes they will still be done

Member

arschmitz commented Feb 9, 2016

the changes i mentioned are things slated for 1.6 regardless of this change so yes they will still be done

@arschmitz arschmitz reopened this Feb 9, 2016

@arschmitz arschmitz closed this Feb 9, 2016

@dpolivy

This comment has been minimized.

Show comment
Hide comment
@dpolivy

dpolivy Feb 9, 2016

@arschmitz Any timeline for 1.6 to be released?

dpolivy commented Feb 9, 2016

@arschmitz Any timeline for 1.6 to be released?

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Feb 23, 2016

Contributor

More news from the WebKit team:
https://bugs.webkit.org/show_bug.cgi?id=153686#c2

We actually reverted to dispatching popstate synchronously in all cases, due to compatibility concerns: http://trac.webkit.org/changeset/196807. We're going to file a spec issue rather than try to be the only browser that conforms to this part of the spec.

Contributor

jokeyrhyme commented Feb 23, 2016

More news from the WebKit team:
https://bugs.webkit.org/show_bug.cgi?id=153686#c2

We actually reverted to dispatching popstate synchronously in all cases, due to compatibility concerns: http://trac.webkit.org/changeset/196807. We're going to file a spec issue rather than try to be the only browser that conforms to this part of the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment