Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
HTML5 issues — Gideros Forum
  • Home
    • ›

    HTML5 issues

    PaulHPaulH Member
    in General questions
    I could use some help understanding some HTM5 export issues.

    The app I've been working on for the last year, a 3D simulation of tying fishing flies, will be published on the mobile app stores soon, but I'm using an HTML5 version to let people try it out before release. I've had some odd issues with HTML5 exports that I've tried to pin down for some time. Sometimes an export opens fine, and sometimes the colored wheel spins forever. From what I can tell this seems to be a pattern:

    If I include the domain name in the export, including the "www.", the app will run in Chrome on Windows or iOS, but won't open running Chrome on Android. If I leave off the "www." it's the opposite, opening on Android but not on Windows or iOS. I currently have links to an app exported both ways on www.flytyingsimulator.com. The first link (labeled for Windows and iOS) was exported with the www.flytyingsimulator.com domain, and the second link (labeled for Android/iOS) was exported with a domain of just flytyingsimulator.com. In all cases I'm exporting with "encrypt code" and "encrypt assets" checked, but nothing else.

    Am I missing something, or is this a bug?

    If I'm right about the pattern I suppose I can make a landing page that redirects to one export version or the other based on the detectOS() JavaScript function.

    Another thing I'm seeing from HTML5 exports is URLLoaders don't seem to be working. On some platforms I find I can load a file only with an "HTTPS://" prefix, and on others only with "HTTP://", so I have the code attempt to load a tiny text file (I use www.pishtech.com/nettest.txt) twice, one with each protocol, and whichever one works, that's the protocol I'll include in the URLs for all URLLoaders during that session. On HTML5 the load fails both ways, triggering and Event.ERROR. If I leave off the protocol completely and just try to load www.pishtech.com/nettest.txt, I get an Event.COMPLETE, but the resulting data is a 404 Not Found error, not the contents of the file.

    Is anyone using URLLoaders in an HTML5 export? If so is there anything special to know?

    In this case the reason I'm using URLLoaders is to minimize the size and thus the load time for the app. It has a few MB of optional textures it may display for in-app user instruction, and I have it download them in the background. That way the app has almost no graphical assets, so it downloads and starts quickly, and the images are very likely downloaded and ready to show when they're needed. If not the app just shows the instructional text without the image.

    Paul

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook

    Comments

    • hgy29hgy29 Maintainer
      I use URLLoader a lot in one of my apps, and so far it works fine in HTML, both with desktop and mobile browsers. The only thing to know is that Gideros will use XHR or fetch API in the browser to perform the requests, so all standard browser protection mechanisms apply: CORS, http/https mixing, etc. If anything goes wrong, you can use your browser développer tools to diagnose the issue.

      Likes: MoKaLux

      +1 -1 (+1 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      PaulH said:


      If I include the domain name in the export, including the "www.", the app will run in Chrome on Windows or iOS, but won't open running Chrome on Android. If I leave off the "www." it's the opposite, opening on Android but not on Windows or iOS.

      Gideros checks the domain name specified in the export againts what the browsers report in JavaScript location.href variable, more specifically it checks for an exact match of whatever comes after the first "://" and before the next "/" in location.href. If you have to change the domain name, that would mean that browsers don't report the same location depending on the OS.

      Could this be due to redirects or DNS canonical name for your site ?
      +1 -1Share on Facebook
    • PaulHPaulH Member
      I don't know enough about the web hosting system to have a clue why some browsers might report location.href with the "www" and some without, but for now I've got the landing page looking at that and showing a link to the HTML5 export that matches that location, and that works.

      For the UrlLoaders on HTML5, I've learned more about what's going on:

      If I use a loader to access a web API, that API will run (I see database entries reflecting the API call) but it looks like Gideros will only get an Event.COMPLETE with the output of that API if the API is on the domain for which the project was exported. Otherwise it gets an Event.ERROR and no data from the API.

      In my case, to test network access I have the app on flytyingsimulator.com try to access a text file on pishtech.com, and I get the error event. Moving the same text file to flytyingsimulator.com and accessing it there works.

      Likes: MoKaLux

      +1 -1 (+1 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      PaulH said:


      In my case, to test network access I have the app on flytyingsimulator.com try to access a text file on pishtech.com, and I get the error event. Moving the same text file to flytyingsimulator.com and accessing it there works.

      That would be a CORS issue then, your navigator will ask pishtech.com wether, it accepts to be queried from flytyingsimulator.com and pishtech.com would respond no, or nothing which is is the same.
      You should configure pishtech.com so that it includes a response header like
      Access-Control-Allow-Origin: *
      for the request you are issuing.

      +1 -1Share on Facebook
    • PaulHPaulH Member
      I think there may be more going on here. I just tried exporting a player with no domain, and opening that with a browser where location.href does not include the www. It can successfully access the file on either domain without the www, getting an Event.COMPLETE:

      https://flytyingsimulator.com/nettest.txt
      https://pishtech.com/nettest.txt

      But it can't access either with the www, getting an Event.ERROR:
      https://www.flytyingsimulator.com/nettest.txt
      https://www.pishtech.com/nettest.txt

      Both are add-on domains on the same virtual private server. So this doesn't seem to be an issue with the domain an HTML5 export is targeted to, or whether it's accessing something on a domain different from the one where it's running. Rather it seems as though in cases where the variable location.href includes the www, it will only succeed in accessing those two domains if they include the www, and vice versa.

      Yet in the same browser I can open the test file (nettest.txt) either with or without the www.

      I remain confused.
      +1 -1Share on Facebook
    • PaulHPaulH Member
      edited February 28
      Now even that doesn't seem to be consistent. I just ran a test of four ways to access the file in a player with no domain included: with and without "www.", and with either HTTP or HTTPS, and all four triggered Event.ERROR. I'm still digging, and consulting my web host for why the location.href variable isn't consistent.
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      It would be interesting to look at the browser's network log, in developper console. It should report why the requests failed
      +1 -1Share on Facebook
    • PaulHPaulH Member
      You're correct: The console shows the CORS policy blocked the requests. I didn't expect this as I've never had issues with scripts on one of my domains accessing files on the others. I just put a PHP script on flytyingsimulator.com to read and echo the contents of the test file on pishtech.com, and it works fine: <?php echo(file_get_contents("https://www.pishtech.com/nettest.txt")); ?>

      It even works with both https and https, both with and without "www." in the URL. I expected access between the two domains to work within an HTML5 export too, but I'm unfamiliar with CORS. I'll educate myself a least a little on that.

      Thanks!

      Paul

      Likes: MoKaLux

      +1 -1 (+1 / -0 )Share on Facebook
    Sign In or Register to comment.