Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

SugarCube: Two questions (page title, IE compatibility)

Hello! After working with an earlier version of SugarCube (somewhere in the 2700s, I think), I downloaded version 3001 today. Two things came up:

1) The page title has reverted to "SugarCube" instead of automatically matching my StoryTitle. Is that intentional? If so, I discovered that I can use <<set document.title>> to change it, but I'm not sure if that's the correct practice.

2) I use Firefox, so I've been doing all my reading and testing only there. Today I decided to look at my story in IE 10 (I'm on Windows 7 64-bit). At IE 10's default medium-high security setting, the story puts up the "You must enable JavaScript" message, and IE 10 produces the "Allow blocked content" prompt for "scripts and ActiveX controls." When I click to allow, the story gives an "Apologies! There is a technical problem..." dialog that says "Error: Invalid operand to 'in': Object expected". If I click OK, the story shows "Loading Story Resources" but never loads.

I tried again with a plain, new story (just the Start passage) in SugarCube, and the same things happened, so I figure the culprit isn't something unique in my real story. Am I missing something?

Regardless, I have to say that I love SugarCube: It addresses all of the things about the other formats that I found problematic. Thanks very much for any help!

Comments

  • TEYV wrote:

    1) The page title has reverted to "SugarCube" instead of automatically matching my StoryTitle. Is that intentional? If so, I discovered that I can use <<set document.title>> to change it, but I'm not sure if that's the correct practice.


    No, that's a bug.


    TEYV wrote:

    2) I use Firefox, so I've been doing all my reading and testing only there. Today I decided to look at my story in IE 10 (I'm on Windows 7 64-bit). At IE 10's default medium-high security setting, the story puts up the "You must enable JavaScript" message, and IE 10 produces the "Allow blocked content" prompt for "scripts and ActiveX controls." When I click to allow, the story gives an "Apologies! There is a technical problem..." dialog that says "Error: Invalid operand to 'in': Object expected". If I click OK, the story shows "Loading Story Resources" but never loads.

    I tried again with a plain, new story (just the Start passage) in SugarCube, and the same things happened, so I figure the culprit isn't something unique in my real story. Am I missing something?


    No, that's a bug too.  I generally test in Firefox, Chrome, IE, and Opera, but I must not have tested the current release in IE.  /sigh


    I'll get both of those fixed for the next release.
  • TheMadExile, thanks for your reply! Not sure if it's relevant, but I should have mentioned too that I am using Twine 1.3.6 alpha and the corresponding "older Twine" version of SugarCube.
  • Ah.  Thanks for the update.  :)

    As it turns out, it (thankfully) isn't relevant in this case, as both builds of SugarCube are made from the same codebase.  Actually, the only difference between them is that the Twine/Twee 1.4+ version supports features introduced by that version of Twine, while the "old" (classic?) version does not.  The only reason that there's a classic build to begin with is that some of the new 1.4+ features are incompatible with old compilers, so they require their own build.
  • Both of these are fixed in the repo and will be in the next release.
  • Thanks very much for the fixes!

    Now that I can see the story in IE, I have one other question. When I click Saves in IE, I get only the Save to Disk and Load to Disk buttons, and no slots. Does IE not support the save slots?
  • TEYV wrote:

    Now that I can see the story in IE, I have one other question. When I click Saves in IE, I get only the Save to Disk and Load to Disk buttons, and no slots. Does IE not support the save slots?


    Presuming that feature detection works as it should, a player/user will only see what their browser currently supports w/r/t the saves system.  For example, if the browser in question doesn't support one of the various features required for the Save to/Load from Disk feature, then the player shouldn't see that feature exposed.  So, if the browser in question doesn't currently support the localStorage feature, then the player won't see the save slots exposed.

    The reason I've emphasized the word currently in the above is because it is, unfortunately, not simply a matter of what features a particular browser nominally supports, but also a question of which of those features might be disabled because of:
    • Current security settings (i.e. local vs. intranet vs. internet settings, etc).
    • Current mode (i.e. private browsing, kiosk, etc).
    • User action (i.e. features that are togglable/optional).
    In your case, you're probably looking at the story locally in IE, which has probably disabled localStorage because of IE's default security settings.  If you were to open the story via HTTP, say from a website or via a micro-webserver (e.g. Mongoose), then you'd likely see saves slots in IE.
  • Ah, yes, I understand now. I uploaded my story and looked at it in IE, and now the save slots show up perfectly (and the story loads instantly...IE doesn't toss up that Allow Blocked Content button). Thanks very much again!
  • Trouble seems to be following me whenever I try to test out my story.  :-\

    I just tried looking at it in Safari on Mac (via the Web, not locally), and I got the "Apologies" dialog. It said, "Error: TypeError: 'undefined' is not an object". The story didn't load at all. Is this a new problem, or has Safari always been on unfriendly terms with SugarCube?
  • Off the top of my head, I don't recall any reported issues with Safari (but that doesn't mean there weren't any).  I don't have a Mac, so my testing ability here is limited.

    Does the console offer any extra information?
  • Safari's console gives me one error:
    TypeError: 'undefined' is not an object (evaluating 'this.history.length')

    It then gives me three warnings, two of which say:
    Resource interpreted as Font but transferred with MIME type font/woff.
    These two warnings seem to correspond with the two Google Fonts I'm using. Although the story is broken in Safari and doesn't load the start passage or my CSS tweaks, it does load the sidebar, and I can see my fonts in use there.

    There's also a third warning that's similar:
    Resource interpreted as Font but transferred with MIME type application/font-woff.
    I can't comprehend this one at all because it starts with "data:application/font-woff;charset=utf-8;base64" but continues with seemingly endless lines of gibberish. (I'm afraid that trying to paste all that here would break the forum or something.)
  • My project using the latest SugarCube works fine in Safari 6.1. However, I am using the version of SugarCube for Twee, not for Twine 1.4.x. So maybe there's an issue between the two versions....
  • This is interesting. The error I reported earlier was in Safari on the Mac I have at work (not sure what version of Safari it is, though), and it was repeatable. But I just got my hands on a MacBook with Safari 6.0, and my story loaded fine. So now I'm not sure what's going on.
  • The version of Safari at your workplace is likely less than 6.0, since, AFAIK, WOFF fonts have been supported in Safari since 5.1-ish.  Please check the version of Safari at your workplace when you get a chance.

    Also, the "data:application/font-woff;charset=utf-8;base64," warning comes from SugarCube's own embedded PUA icon font.

    [EDIT]
    And I have no idea why it's moaning about this.history.length being undefined.  That should be impossible.  The only place references to this.history.length appear are within the History prototype itself (which is instantiated once, as the variable state), and its constructor instantiates this.history as an array.

    On the bright side, I was able to get the same warning about the font (which seems ignorable since it still works) and the this.history.length undefined error in the last Windows version of Safari they produced (5.1.7).
  • Okay.  I've tracked down the history issue and I've created a polyfill to work around the problem in affected browsers (maybe all Apple WebKit browserscaniuse shows iOS 5+ as being okay, while showing all versions of desktop Safari as being hosed, so I don't know).  The polyfill isn't 100% effective, however, affected browsers will lose their current history state if the user forces a page reload, which will drop them back at the Start passage (all of the previous states are still there, just the current one is lost).  I don't believe there's any fix for the reload issue here, other than simply to not do it.
  • Ah, that explains it. I did get around to checking the version of Safari on my work machine, and it is indeed 5.1.3. All this time, and I had no idea that a 2.5-year-old browser was still hanging around there. (I use Firefox even on Mac...I am really not much of an Apple fan.) At any rate, thanks very much for looking into all my questions!
Sign In or Register to comment.