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

$("a").live("click") returns different values on desktop browsers and on iOS safari since jQuery Mobile 1.1.0 RC1 #3686

Closed
JFK99 opened this Issue Feb 29, 2012 · 10 comments

Comments

Projects
None yet
9 participants
@JFK99
Contributor

JFK99 commented Feb 29, 2012

I capture an event on a click with $("a").live("click"), from that, I want to get the href property of the this link clicked with this.href.
Here is a quick example:
Render: http://jsbin.com/ocezih/3
Code: http://jsbin.com/ocezih/3/edit#javascript,html

On iOS simulator safari and iOS device safari it returns me # as a link
On desktop chrome and safari, it returns the actual value of the href property

Problem appears on 1.1.0 RC1 but works on 1.0.

@eddiemonge

This comment has been minimized.

Show comment
Hide comment
@eddiemonge

eddiemonge Mar 1, 2012

Contributor

.live() is deprecated

Contributor

eddiemonge commented Mar 1, 2012

.live() is deprecated

@eddiemonge

This comment has been minimized.

Show comment
Hide comment
@JFK99

This comment has been minimized.

Show comment
Hide comment
@JFK99

JFK99 Mar 1, 2012

Contributor

Thanks Eddie!
Nice catch, I changed the live() to on() and reverse the condition. It works on desktop browsers and ios safari
http://jsbin.com/ocezih/56/edit
http://jsbin.com/ocezih/56
:)

Contributor

JFK99 commented Mar 1, 2012

Thanks Eddie!
Nice catch, I changed the live() to on() and reverse the condition. It works on desktop browsers and ios safari
http://jsbin.com/ocezih/56/edit
http://jsbin.com/ocezih/56
:)

@JFK99 JFK99 closed this Mar 1, 2012

@gseguin

This comment has been minimized.

Show comment
Hide comment
@gseguin

gseguin Mar 2, 2012

Member

We traced the problem down to a change in the order the bound and delegated handlers are executed in jQuery 1.7.1 (thanks to @dmethvin and @jblas).

Using jQuery 1.6.4 with jQuery Mobile 1.1-RC1 is the recommended workaround. We'll address the problem before jQuery Mobile 1.1 final.

As a side note, in your example you're using a non supported syntax for live. According to http://api.jquery.com/live/ :

Chaining methods is not supported. For example, $("a").find(".offsite, .external").live( ... ); is not valid and does not work as expected.

Member

gseguin commented Mar 2, 2012

We traced the problem down to a change in the order the bound and delegated handlers are executed in jQuery 1.7.1 (thanks to @dmethvin and @jblas).

Using jQuery 1.6.4 with jQuery Mobile 1.1-RC1 is the recommended workaround. We'll address the problem before jQuery Mobile 1.1 final.

As a side note, in your example you're using a non supported syntax for live. According to http://api.jquery.com/live/ :

Chaining methods is not supported. For example, $("a").find(".offsite, .external").live( ... ); is not valid and does not work as expected.

@gseguin gseguin reopened this Mar 2, 2012

@gseguin gseguin closed this in b52d7ca Mar 8, 2012

@gseguin gseguin reopened this Mar 8, 2012

@gseguin

This comment has been minimized.

Show comment
Hide comment
@gseguin

gseguin Mar 8, 2012

Member

I had to revert the commit as it was causing major breakage of our tests.

Member

gseguin commented Mar 8, 2012

I had to revert the commit as it was causing major breakage of our tests.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Mar 8, 2012

Member

Probably needs code to normalize event.which, since it's not going through jQuery's event normalization. The event.target reference should be okay, but event.preventDefault() needs to be shimmed in oldIE.

Member

dmethvin commented Mar 8, 2012

Probably needs code to normalize event.which, since it's not going through jQuery's event normalization. The event.target reference should be okay, but event.preventDefault() needs to be shimmed in oldIE.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Mar 9, 2012

Contributor

@scottjehl @toddparker @gseguin

Hey Scott,

Is there any other way we can try to prevent the location bar from dropping? IMO we shouldn't be outright changing hrefs for links for exactly the reason this bug is about ... we don't know what developers are going to be doing in the events/notifications triggered by the framework processing of the link.

Contributor

jblas commented Mar 9, 2012

@scottjehl @toddparker @gseguin

Hey Scott,

Is there any other way we can try to prevent the location bar from dropping? IMO we shouldn't be outright changing hrefs for links for exactly the reason this bug is about ... we don't know what developers are going to be doing in the events/notifications triggered by the framework processing of the link.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Mar 9, 2012

Contributor

I'm unsure there is.

Before implementing this, I did several isolated tests and found that changing the href to a hash-based value was the only way to prevent it, short of handling touch events that is.

I agree though, what we're doing here is not ideal, and potentially problematic for developers. Not sure what to recommend, since the virtual/touch events can't be trusted entirely for navigation...

On Mar 9, 2012, at 10:59 PM, Kin Blas wrote:

@scottjehl @toddparker @gseguin

Hey Scott,

Is there any other way we can try to prevent the location bar from dropping? IMO we shouldn't be outright changing hrefs for links for exactly the reason this bug is about ... we don't know what developers are going to be doing in the events/notifications triggered by the framework processing of the link.


Reply to this email directly or view it on GitHub:
#3686 (comment)

Contributor

scottjehl commented Mar 9, 2012

I'm unsure there is.

Before implementing this, I did several isolated tests and found that changing the href to a hash-based value was the only way to prevent it, short of handling touch events that is.

I agree though, what we're doing here is not ideal, and potentially problematic for developers. Not sure what to recommend, since the virtual/touch events can't be trusted entirely for navigation...

On Mar 9, 2012, at 10:59 PM, Kin Blas wrote:

@scottjehl @toddparker @gseguin

Hey Scott,

Is there any other way we can try to prevent the location bar from dropping? IMO we shouldn't be outright changing hrefs for links for exactly the reason this bug is about ... we don't know what developers are going to be doing in the events/notifications triggered by the framework processing of the link.


Reply to this email directly or view it on GitHub:
#3686 (comment)

@ldeluca

This comment has been minimized.

Show comment
Hide comment
@ldeluca

ldeluca Oct 22, 2014

Contributor

@scottjehl @JFK99 There hasn't been any updates or comments on this issue in over 2 years. Can you confirm if it's still an issue with the latest jQM version or if this can be closed? Thanks

Contributor

ldeluca commented Oct 22, 2014

@scottjehl @JFK99 There hasn't been any updates or comments on this issue in over 2 years. Can you confirm if it's still an issue with the latest jQM version or if this can be closed? Thanks

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Oct 22, 2014

Member

These core versions are no longer supported infact we don't support any core version in which live is not deprecated. ( and only one version where it exists at all ) i'm going to close this.

Member

arschmitz commented Oct 22, 2014

These core versions are no longer supported infact we don't support any core version in which live is not deprecated. ( and only one version where it exists at all ) i'm going to close this.

@arschmitz arschmitz closed this Oct 22, 2014

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