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

Navigation: Deep linking doesn't work on OSX Yosemite Safari 8.0 on Browserstack #8056

Closed
gabrielschulhof opened this Issue Apr 2, 2015 · 28 comments

Comments

Projects
None yet
3 participants
@gabrielschulhof
Contributor

gabrielschulhof commented Apr 2, 2015

http://jsbin.com/jobaho/4.html#/wubowa/4.html&ui-state=dialog
Should result in the start page (wubowa) being shown. It's shown, but then it transitions to the redirect page (jobaho).

@gabrielschulhof gabrielschulhof self-assigned this Apr 2, 2015

@gabrielschulhof gabrielschulhof added this to the 1.5.0 milestone Apr 2, 2015

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

I cannot confirm this on OSX Yosemite with Chrome, Safari, or Firefox? what are you seeing this on? OSX is pretty broad i doubt this is a general OSX issue across all browsers? What version of OSX?

Member

arschmitz commented Apr 2, 2015

I cannot confirm this on OSX Yosemite with Chrome, Safari, or Firefox? what are you seeing this on? OSX is pretty broad i doubt this is a general OSX issue across all browsers? What version of OSX?

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Sorry! Safari.

Contributor

gabrielschulhof commented Apr 2, 2015

Sorry! Safari.

@gabrielschulhof gabrielschulhof changed the title from Navigation: Deep linking doesn't work on OSX to Navigation: Deep linking doesn't work on OSX Safari Apr 2, 2015

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

@gabrielschulhof What OSX? As i said i cannot confirm on OSX Yosemite Safari 8

Member

arschmitz commented Apr 2, 2015

@gabrielschulhof What OSX? As i said i cannot confirm on OSX Yosemite Safari 8

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

OK, weird. I was using Browserstack.

Contributor

gabrielschulhof commented Apr 2, 2015

OK, weird. I was using Browserstack.

@gabrielschulhof gabrielschulhof changed the title from Navigation: Deep linking doesn't work on OSX Safari to Navigation: Deep linking doesn't work on OSX Yosemite Safari 8.0 on Browserstack Apr 2, 2015

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

OK, I accidentally changed the jsbin link to point to my local copy which already has the fix. I'll update the test page.

Contributor

gabrielschulhof commented Apr 2, 2015

OK, I accidentally changed the jsbin link to point to my local copy which already has the fix. I'll update the test page.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

@gabrielschulhof Well browserstack has 5 versions of OSX which one?

Member

arschmitz commented Apr 2, 2015

@gabrielschulhof Well browserstack has 5 versions of OSX which one?

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Yosemite.

Contributor

gabrielschulhof commented Apr 2, 2015

Yosemite.

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

The above link should reproduce the problem on Safari 8 running on OSX Yosemite. It should reproduce with or without Browserstack, though I cannot test without Browserstack.

Contributor

gabrielschulhof commented Apr 2, 2015

The above link should reproduce the problem on Safari 8 running on OSX Yosemite. It should reproduce with or without Browserstack, though I cannot test without Browserstack.

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Dang! The link is still wrong!

Contributor

gabrielschulhof commented Apr 2, 2015

Dang! The link is still wrong!

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

@gabrielschulhof the original test page does not point to a local copy it points to git and works fine in OSX Safari 8 Yosemeti and browser stack the updated # 4 jsbin is exactly the same and still works fine both places

Member

arschmitz commented Apr 2, 2015

@gabrielschulhof the original test page does not point to a local copy it points to git and works fine in OSX Safari 8 Yosemeti and browser stack the updated # 4 jsbin is exactly the same and still works fine both places

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

OK, then I must be dreaming. I'll make a video.

Contributor

gabrielschulhof commented Apr 2, 2015

OK, then I must be dreaming. I'll make a video.

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

@gabrielschulhof there is indeed a transition flash there but the URL at the end if you check it is http://jsbin.com/wubowa/4.html&ui-state=dialog which is what it should be.

Member

arschmitz commented Apr 2, 2015

@gabrielschulhof there is indeed a transition flash there but the URL at the end if you check it is http://jsbin.com/wubowa/4.html&ui-state=dialog which is what it should be.

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Right, but the page isn't. It's the redirect page, not the start page.

Contributor

gabrielschulhof commented Apr 2, 2015

Right, but the page isn't. It's the redirect page, not the start page.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

You never show that in anyway way in your test page or video since the start and destination page are identical. and you never show the inspector to show this either. However the whole thing is cause because your url is invalid

http://jsbin.com/jobaho/4.html#http://jsbin.com/wubowa/4.html&ui-state=dialog should be http://jsbin.com/jobaho/4.html#http://jsbin.com/wubowa/4.html?ui-state=dialog

You could also see there was an error in the console about invalid data type and aborting the connection due to this.

Member

arschmitz commented Apr 2, 2015

You never show that in anyway way in your test page or video since the start and destination page are identical. and you never show the inspector to show this either. However the whole thing is cause because your url is invalid

http://jsbin.com/jobaho/4.html#http://jsbin.com/wubowa/4.html&ui-state=dialog should be http://jsbin.com/jobaho/4.html#http://jsbin.com/wubowa/4.html?ui-state=dialog

You could also see there was an error in the console about invalid data type and aborting the connection due to this.

@arschmitz arschmitz closed this Apr 2, 2015

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

I've fixed the URL in the original post, and I've reproduced the issue with that URL on an actual, physical iOS 6.1.2 iPod Touch.

It's not reproducible 100% of the time, because I suspect there's a race condition between our initial redirect when encountering an initial URL that requires an Ajax page load, and the arrival of the spurious popstate that Webkit produces.

The fix for this issue, which I already have handy, also fixes a problem that arises in 1.5-dev after you remove the defaults dependency on json!../package.json. This causes the load order to change when using requirejs and, for some reason, causes the phantomjs initial popstate to break our redirect sequence tests.

That's how I got the idea of testing this on Safari - since it's the only Webkit-based browser (aside probably from old Android).

I've also created a video illustrating how a URL of a form <domain>/path/to/file1.html#/path/to/file2.html&ui-state=dialog might arise. Hint: Alice runs an app on IE8 which does not support pushState, copies the location and sends it to Bob, who's running Safari:

https://www.youtube.com/watch?v=X5RK3MGhdWE

Contributor

gabrielschulhof commented Apr 2, 2015

I've fixed the URL in the original post, and I've reproduced the issue with that URL on an actual, physical iOS 6.1.2 iPod Touch.

It's not reproducible 100% of the time, because I suspect there's a race condition between our initial redirect when encountering an initial URL that requires an Ajax page load, and the arrival of the spurious popstate that Webkit produces.

The fix for this issue, which I already have handy, also fixes a problem that arises in 1.5-dev after you remove the defaults dependency on json!../package.json. This causes the load order to change when using requirejs and, for some reason, causes the phantomjs initial popstate to break our redirect sequence tests.

That's how I got the idea of testing this on Safari - since it's the only Webkit-based browser (aside probably from old Android).

I've also created a video illustrating how a URL of a form <domain>/path/to/file1.html#/path/to/file2.html&ui-state=dialog might arise. Hint: Alice runs an app on IE8 which does not support pushState, copies the location and sends it to Bob, who's running Safari:

https://www.youtube.com/watch?v=X5RK3MGhdWE

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

The root cause seems to be that, while we identify the spurious popstate in navigator, we do not prevent default on it, because the location.href at that time is not the same as the location.href we record duing the loading of navigator. We then do a squash() from init, causing the location.href to change. So, when the spurious popstate arrives, the location is no longer of the form path1/path2, because of the squash() we ran from init, so the default for the spurious popstate is not prevented, causing a navigate event, which pagecontainer handles incorrectly.

Contributor

gabrielschulhof commented Apr 2, 2015

The root cause seems to be that, while we identify the spurious popstate in navigator, we do not prevent default on it, because the location.href at that time is not the same as the location.href we record duing the loading of navigator. We then do a squash() from init, causing the location.href to change. So, when the spurious popstate arrives, the location is no longer of the form path1/path2, because of the squash() we ran from init, so the default for the spurious popstate is not prevented, causing a navigate event, which pagecontainer handles incorrectly.

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

I'd sure like to see someone else reproduce this issue though ...

Contributor

gabrielschulhof commented Apr 2, 2015

I'd sure like to see someone else reproduce this issue though ...

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Just to recap: Steps to reproduce:

  1. Visit http://jsbin.com/jobaho/4.html#/wubowa/4.html&ui-state=dialog from some version of Safari. The more versions/OSs we try the better.
  2. Read the title in the header

If you see "Redirect", the bug is present.
If you see "Start Page", the behaviour is correct.

Contributor

gabrielschulhof commented Apr 2, 2015

Just to recap: Steps to reproduce:

  1. Visit http://jsbin.com/jobaho/4.html#/wubowa/4.html&ui-state=dialog from some version of Safari. The more versions/OSs we try the better.
  2. Read the title in the header

If you see "Redirect", the bug is present.
If you see "Start Page", the behaviour is correct.

gabrielschulhof added a commit that referenced this issue Apr 2, 2015

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Safari 7/Mavericks on Browserstack also reproduces the issue.

Contributor

gabrielschulhof commented Apr 2, 2015

Safari 7/Mavericks on Browserstack also reproduces the issue.

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Apr 2, 2015

Member

I tested on OS X Yosemite 10.10.2 / Safari 8.0.4 and don't see the issue (title is "Start Page").

Member

jaspermdegroot commented Apr 2, 2015

I tested on OS X Yosemite 10.10.2 / Safari 8.0.4 and don't see the issue (title is "Start Page").

gabrielschulhof added a commit to gabrielschulhof/jquery-mobile that referenced this issue Apr 2, 2015

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

@jaspermdegroot Can you try iOS?

Contributor

gabrielschulhof commented Apr 2, 2015

@jaspermdegroot Can you try iOS?

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

@jaspermdegroot Also, can you try loading the URL multiple times?

Contributor

gabrielschulhof commented Apr 2, 2015

@jaspermdegroot Also, can you try loading the URL multiple times?

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

well after 40+ reloads i managed to break it some how this is seeming pretty obscure. i feel like if you reload any page with enough JS going on enough times in a tight loop something will hiccup once in a while lol

Member

arschmitz commented Apr 2, 2015

well after 40+ reloads i managed to break it some how this is seeming pretty obscure. i feel like if you reload any page with enough JS going on enough times in a tight loop something will hiccup once in a while lol

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Apr 2, 2015

Contributor

Well, it's pretty reliable on iOS 6.1.2 on my iPod. Have you tried multiple iDevices? Also, a straight-up reload is not enough, because it does the replace state. You actually need to paste in the URL and hit Enter repeatedly.

Contributor

gabrielschulhof commented Apr 2, 2015

Well, it's pretty reliable on iOS 6.1.2 on my iPod. Have you tried multiple iDevices? Also, a straight-up reload is not enough, because it does the replace state. You actually need to paste in the URL and hit Enter repeatedly.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 2, 2015

Member

only iphone 6 ios 8 but yes i was repasting the url each time

Member

arschmitz commented Apr 2, 2015

only iphone 6 ios 8 but yes i was repasting the url each time

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Apr 3, 2015

Member

The first time I tested I just clicked on the link. When I copy and paste the url and hit enter I can easily reproduce. Every time I briefly get to see the "Start Page" and then the "Redirect" page.
This is still on MBP OS X Yosemite 10.10.2 / Safari 8.0.4. On Chrome on the same machine I always get the "Start Page".
Haven't tested on iPhone and iPad yet.

Member

jaspermdegroot commented Apr 3, 2015

The first time I tested I just clicked on the link. When I copy and paste the url and hit enter I can easily reproduce. Every time I briefly get to see the "Start Page" and then the "Redirect" page.
This is still on MBP OS X Yosemite 10.10.2 / Safari 8.0.4. On Chrome on the same machine I always get the "Start Page".
Haven't tested on iPhone and iPad yet.

gabrielschulhof added a commit to gabrielschulhof/jquery-mobile that referenced this issue Apr 8, 2015

kakul added a commit to kakul/jquery-mobile that referenced this issue Apr 14, 2015

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