[Bug] Load, reload, oops! no Stylish

edited December 2013 in userstyles.org
In Firefox 25,
  1. Load a style page, say http://userstyles.org/styles/96293
    Page says "Install with Stylish" - all is well
  2. Open a new tab, load the same page.
    Page says "To use this style, install Stylish" - no, that's not right.
  3. Restart Firefox - no joy.
  4. For many styles I'm not given the option to "Install" at all - just "To use this style, install Stylish"
Something's kerflooey with the caching.

This isn't happening in Chrome. This is happening in Chrome as well. And now it isn't. [grr!]

Comments

  • The detection to see if Stylish or a specific style is in JS, so caching should not be an issue...

    I recently changed the JS around, potentially there's a timing thing, but I've never seen any problems.
  • Haven't looked into it yet. Some pages worked then failed on reload, other pages failed on the first load, so it seemed like a site-side caching or compression issue. I don't understand either how that could affect add-on detection (site and add-on pass messages, yes?), but then I don't see how anything but dropping a message could cause it, and no changes in the page content or compression could cause that.
  • My guess would be there's now a race between Stylish saying "this can be installed" (which happens on DOMContentLoaded) and the JS on the site listening for it (which happens in a deferred script). I'll see what I can do to resolve that.
  • I moved the code that adds the listeners on the site from DOMContentLoaded to when script defer runs, but that doesn't seem to have helped. Deferred scripts are supposed to run before DOMContentLoaded, but apparently don't.
  • OK, so you too see this happen intermittently now, or no?

    For now I'm forcing the Install button with
    #stylish-installed-style-installed[style="display: none"]
    ~ #stylish-installed-style-needs-update[style="display: none"]
    ~ #stylish-installed-style-not-installed {
    display: inline-block !important;
    }
    so it isn't currently more than a nuisance.
  • Yes, only on Firefox, depending on what combination of reload/force-reload I use...
  • I think I fixed it, let me know what you see.
  • Well, I haven't seen it since, so I believe that you did.
  • It's happening again. Did you just switch CDNs?
  • edited February 2014
    Same CDN, different URL.

    The site will log things out to the console related to this... maybe check what it says?
  • If you're using NoScript extension, you must at least add 723d.https.cdn.softlayer.net to the whitelist.
  • edited February 2014
    That was my problem, LouCypher. Thanks!
    The site will log things out to the console related to this... maybe check what it says?
    "Recording styleCanBeInstalled for dispatching later." Um, OK?

    Three images are still 404: https://723d.https.cdn.softlayer.net/images/good.gif, /images/bad.gif, /images/ok.png.
  • edited February 2014
    The images path is /80723D/static.userstyles.org/images/.

    The path in CSS are wrong though, should be url(../images/good.gif), not url(/images/good.gif)
    https://github.com/JasonBarnabe/userstyles/blob/master/app/assets/stylesheets/userstyles.css#L535-L545
    because stylesheet path has moved to /80723D/static.userstyles.org/assets/
  • Fixed now, thanks for letting me know.

    As you can probably guess, the site's going to be switching to https soon. Moving to an HTTPS URL for the CDN was one step in that process.
Sign In or Register to comment.