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

URL handling and PlayBook Webworks app #2050

Closed
snardone opened this Issue Jul 10, 2011 · 10 comments

Comments

Projects
None yet
6 participants
@snardone

snardone commented Jul 10, 2011

Hi guys, great project!

I'm having an issue with 1.0b1 and currently nightly in a PlayBook Webworks app. I have an app with a single HTML file with multiple pages defined. Transitioning between pages using the #id hash reference worked fine up to 1.0a4 but in 1.0b1 each transition just goes to the same ("main") page. In current nightly, page transitions cause the "Loading..." message to appear and just stall forever.

I tracked the problem down to the way the PlayBook expresses URLs in a Webworks app. For example, in my app location.href returns the odd-looking "local:/index.html". However, the path object has a method called makeUrlAbsolute which parses and "normalizes" the effective absolute URL. The problem seems to be that this method returns "local:///index.html" for my URLs passed to it (since the "//" expected and always added). This leads to problems in that the page no longer appears to be embedded (the comparison against "documentUrl" fails) and the framework attempts to hopelessly load the page via ajax. It also seems to cause "data-transition" directives to be ignored but I haven't had a chance to investigate that.

Now really I think BlackBerry should conform to standards and location.href should return "local:///index.html" (or how about "file:///index.html"!). But anyway, to work around the problem I modified path.makeUrlAbsolute() as follows:

makeUrlAbsolute: function( relUrl, absUrl ) {
  if ( !path.isRelativeUrl( relUrl ) ) {
    return relUrl;
  }

  var relObj = path.parseUrl( relUrl ),
    absObj = path.parseUrl( absUrl ),
    protocol = relObj.protocol || absObj.protocol,
    separator = (protocol == "local:" ? "" : "//"),   // do not add "//" with PlayBook Webworks
    authority = relObj.authority || absObj.authority,
    hasPath = relObj.pathname !== "",
    pathname = path.makePathAbsolute( relObj.pathname || absObj.filename, absObj.pathname ),
    search = relObj.search || ( !hasPath && absObj.search ) || "",
    hash = relObj.hash;

  return protocol + separator + authority + pathname + search + hash;
  // was ... protocol + "//" + authority ...
},

I'm not sure if such a "hack" is acceptable solution for the project but I thought I'd share it with you. You may have a better solution in mind.

Thanks.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jul 11, 2011

Contributor

Thanks for the detailed analysis. We'll take a look at this and see how to best handle this situation. Your solution seems like a good start!

Contributor

toddparker commented Jul 11, 2011

Thanks for the detailed analysis. We'll take a look at this and see how to best handle this situation. Your solution seems like a good start!

@ghost ghost assigned johnbender Jul 11, 2011

@rubenpal

This comment has been minimized.

Show comment
Hide comment
@rubenpal

rubenpal Aug 9, 2011

Any updates on this? Is the solution above final and acceptable?
The same issue is present as of 1.0b2.
BlackBerry browser has no problems.
When building as an app with WebWorks, "Loading" stalls and no page navigation/transition allowed, single or multipage.
Thanks.

rubenpal commented Aug 9, 2011

Any updates on this? Is the solution above final and acceptable?
The same issue is present as of 1.0b2.
BlackBerry browser has no problems.
When building as an app with WebWorks, "Loading" stalls and no page navigation/transition allowed, single or multipage.
Thanks.

@ghost ghost assigned jblas Aug 11, 2011

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Aug 11, 2011

Contributor

We'll take a look, but we're landing some bigger changes right now for B3 so this might need to wait until we get that out.

Contributor

toddparker commented Aug 11, 2011

We'll take a look, but we're landing some bigger changes right now for B3 so this might need to wait until we get that out.

@ludjer

This comment has been minimized.

Show comment
Hide comment
@ludjer

ludjer Sep 15, 2011

i was looking for a solution to this problem for hours with no help now I finally found it.

I must say thanks so much bigragu you saved me big time bro. If i could i would love to have your babies XD or buy you a beer ;D

at the jquery mobile team this is quite a problem when trying to create a native app on the latest blackberry webworks for the playbook. i was sitting here dumb founded. I would like to see this fixed in the near future.

ludjer commented Sep 15, 2011

i was looking for a solution to this problem for hours with no help now I finally found it.

I must say thanks so much bigragu you saved me big time bro. If i could i would love to have your babies XD or buy you a beer ;D

at the jquery mobile team this is quite a problem when trying to create a native app on the latest blackberry webworks for the playbook. i was sitting here dumb founded. I would like to see this fixed in the near future.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 15, 2011

Contributor

Rather than checking for a specific protocol, let me look into modifying the parser so that it tracks the separator. That way, we can just use absObj.separator versus assuming its "//".

  • Kin
Contributor

jblas commented Sep 15, 2011

Rather than checking for a specific protocol, let me look into modifying the parser so that it tracks the separator. That way, we can just use absObj.separator versus assuming its "//".

  • Kin
@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 15, 2011

Contributor

Ok, I have the URL parser fix for this so it doesn't require us to check for a specific protocol. I'm just testing it before I land.

Contributor

jblas commented Sep 15, 2011

Ok, I have the URL parser fix for this so it doesn't require us to check for a specific protocol. I'm just testing it before I land.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 16, 2011

Contributor

Ok, I just landed the fix on the HEAD. The patch can be found here:

7823497

Contributor

jblas commented Sep 16, 2011

Ok, I just landed the fix on the HEAD. The patch can be found here:

7823497

@jblas jblas closed this Sep 16, 2011

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Sep 16, 2011

Contributor

Great news! I'll tell Laurent.

Sent from my iPhone

On Sep 15, 2011, at 8:01 PM, "Kin Blas" reply@reply.github.com wrote:

Ok, I just landed the fix on the HEAD. The patch can be found here:

7823497

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

Contributor

toddparker commented Sep 16, 2011

Great news! I'll tell Laurent.

Sent from my iPhone

On Sep 15, 2011, at 8:01 PM, "Kin Blas" reply@reply.github.com wrote:

Ok, I just landed the fix on the HEAD. The patch can be found here:

7823497

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

@ludjer

This comment has been minimized.

Show comment
Hide comment
@ludjer

ludjer Sep 16, 2011

awesome work jblas thanks allot.

ludjer commented Sep 16, 2011

awesome work jblas thanks allot.

@snardone

This comment has been minimized.

Show comment
Hide comment
@snardone

snardone Sep 21, 2011

Great approach, thanks for the fix!!

snardone commented Sep 21, 2011

Great approach, thanks for the fix!!

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