Fragment ID (hash) in url of containing HTML causes 1.0.8 b8 to fail

  • I use fragment id's (url hash) to link to specific panoramas in a tour. This has worked fine in 1.0.7, however, with 1.0.8, krpano fails to initialize. It does not even load the XML file. I have verified this by changing only the krpano player version and testing the same page with and without fragment id's.

  • I'm seeing this problem too (although for my implementation it seems to be occurring primarily in Firefox).

    I'm trying to use hashes to make the tours work with the browser back button and bookmarking. Kyle, may I ask for what purpose you are using hash fragments?

    Steve

  • The same purpose, essentially. I want a simple url to link to a specific pano in a tour to enable proper function of the back button and potentially bookmarking. I've had it happen in Firefox 3 and Safari 4, running Flash 10 debugger plugin.

  • Hi,

    I discovered this problem too, but there were no changes in the code regarding this,
    the only thing that has changes is a better/stronger compression of the swf to keep the swf small,

    without doing the re-compressing, the fragment ids (#) work normally...
    I'm sill trying to find the reason for this issue, it's very strange because the # at the html has nothing to do with the embedded flash file...

    (in beta7 the fragment ids should still work)

    best regards,
    Klaus

  • Hmm. That is weird. It doesn't sound like you are talking about obfuscation, since that shouldn't affect file size because swf is byte-code anyway, so it's surprising that any compression algorithm would modify the code at all.

    All I can think of is some buffer length issue when Flash is performing sandbox checking.

  • Klaus, may I ask what you did to fix it? This bug has me interested. It doesn't sound typical at all. If it's getting into trade secrets, never mind. *wink*

    Also, do you have an approximate date for the release of b9? I am looking to deploy soon and want to get an idea of when I'll be able to do so.

    Once again, I'm impressed by your work and your responsiveness. *thumbsup*

  • Klaus, may I ask what you did to fix it? This bug has me interested. It doesn't sound typical at all. If it's getting into trade secrets, never mind. *wink*

    Hi,

    I have just removed the compression of the 'outer' (or better 'main') swf and skipped the problem with it,
    now the swf is around 1kb larger but it works

    there is still an compression on further embedded swfs (which saves around 5kb),
    but this doesn't effect the fragment id problem...

    so what's the real problem is still unknown to me,
    the swf headers and all filesizes were all okay...

    Also, do you have an approximate date for the release of b9? I am looking to deploy soon and want to get an idea of when I'll be able to do so.

    soon, the viewer itself should be ready now (only if I find some bugs in the meantime... )
    at the moment I'm trying in the finish the kprotect tool, when it's ready the new beta 9 will be released,

    best regards,
    Klaus

  • hi klaus

    it seems as if this bug is again or still around.

    i'm having this problem (no pano loading at all when # is entered after url) consistently with 10.1 and 10.2 in Safari and Firefox on Mac (will do further tests on windows). As mentioned here this kind of freaks me out as I can't possibly think of why this happens. Even if I leave away ALL javascript, it still happens.

    You can test it here:
    http://zeitraumaargau.ch/homberg.html -> works
    http://zeitraumaargau.ch/homberg.html# -> doesn't even load

    If there is a chance it has something to do with your compression, please provide one with standard compression. You know, when people are willing to download more than 10mb to browse in a pano, I'm pretty sure they'll survive with another 6kb *wink*

    Any speedy help much appreciated (can't go online with an update because of this and deadline's already over *cry* )

    Cheers /sev

  • Hi,

    just use a newer krpano.swf,
    you are currently using the "krpano 1.0.8 beta 8 (build 2009-06-15)",

    the newer krpano.swf files are not so strong compressed and shouldn't show that error anymore,

    I'm still not sure why that had happen, the compression of the swf file itself shouldn't have
    any effect if there was '#' in the browser url... maybe a strange Flashplayer bug...
    but anyway the newer krpano.sw files should work,

    best regards,
    Klaus

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!