No internet connection
  1. Home
  2. Issues

Some resources loaded twice, warnings and error in console

By Thomas Jensen @thomasjsn2019-05-21 13:16:14.856Z

Six resources seems to be loaded twice;

Warnings in console:

onmozfullscreenchange is deprecated. talkyard-comments.min.js:10:9788
onmozfullscreenerror is deprecated. talkyard-comments.min.js:10:9788

Error in console:

uncaught exception: ok
  • 7 replies
  1. Progress
    with handling this problem
  2. @KajMagnus marked this topic as Planned 2019-05-23 04:36:34.674Z.
  3. KajMagnus @KajMagnus2019-05-23 04:42:21.821Z

    Ok yes it'd be nice to have those warnings + the error disappear. (The uncaught exception: ok is harmless, it's a Promise that decides to fail because service workers won't be used (I haven't enabled those yet). However I should remove that red error line.) Thanks for reporting.

    The duplicated resources — the reason should be that there're in fact 2 iframes: one for the comments, and another for the editor. I would think the browser, with script caching enabled, downloads those scripts just once per script, and then uses the cache. I could investigate if this is indeed the case (or maybe you would want to do that?), and, if not, maybe wait 1 second with creating the editor iframe, so the scripts will have been downloaded and cached before that.

    1. Thomas Jensen @thomasjsn2019-05-23 06:15:17.471Zreplies toKajMagnus:

      Warnings in the console is quite normal, but the error caught my attention. Might be a good idea to get that sorted out :)

      You are right that the second resources are already cached;

      Their cache-control headers instruct both the CDN and the browser to cache;

      tyw-49f8.kxcdn.com:
      cache-control: max-age=2592000, s-maxage=2592000, public
      
      cdn.polyfill.io:
      cache-control: public, s-maxage=31536000, max-age=604800, stale-while-revalidate=604800, stale-if-error=604800
      
      fonts.googleapis.com:
      cache-control: private, max-age=86400
      

      However, seeing as most user will not use the editor at all. Is it possible to defer the editor iframe loading until someone clicks reply?

      1. KajMagnus @KajMagnus2019-05-24 13:31:41.694Z2019-05-24 13:40:23.591Zreplies tothomasjsn:

        Yes that's possible and a good idea I think, because of what you mentioned, and also because this would mean fewer requests to the Talkyard servers & lower load.

        At the same time, there're so many things to do, so probably this won't happen in the nearest future. (It's a bit error prone, to fix this, I'd say, because involves message passing between the comments iframe, and the embedding window, ... and possibly some race conditions to deal with.)

        (B.t.w. I'm also interested in not loading any iframe at all, on "tall" blog post pages where the comments section isn't visible on page load .... until the reader scrolls down, so the comments section scrolls into the viewport. Even lower load, for the servers :- ) & less things to load, on page load, ... might matter marginally for mobiles)

        Thanks for the screenshot and for verifying that the resources get loaded from the cache on the 2nd request.

        1. KajMagnus @KajMagnus2019-05-26 10:42:15.674Z

          Now I've removed the error and warning log messages. The error was because I had forgotten some Promies.catch( ...), and the warnings because https://blissfuljs.com loops through all HTMLElement.prototype fields to find functions to copy to the Bliss object, which accidentally caused these warnings.

          I haven't released / deployed these changes (they're in the master + a work-in-progress branch) .... that'll take maybe 1 more week. I'll leave this open until then.

          1. @KajMagnus marked this topic as Started 2019-05-26 10:42:21.879Z.
          2. KajMagnus @KajMagnus2019-06-09 11:59:25.842Z2019-06-09 12:23:15.864Z

            Hi Thomas now i've deployed the fix that removes the warnigns in FF (as mentioned above), ...

            ... and the service worker error message — however apparently I introduced another (harmless) error: I forgot to specify the correct origin to download the service worker from, when loading the service worker script in an embedded iframe. So there's still an error message about the service worker (a different message). ... Edit: now seems I've fixed this, will be included in the next version.