Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test/Play issues with Twine Online (Firefox) #549

Closed
Callikat opened this issue Apr 25, 2019 · 13 comments
Closed

Test/Play issues with Twine Online (Firefox) #549

Callikat opened this issue Apr 25, 2019 · 13 comments
Labels
bug Something isn't working P2 (should) Usage is significantly impeded, enhancements to cover major functionality gaps

Comments

@Callikat
Copy link

I mentioned this on the Discord earlier, but was referred to put it here too. I'm having a bizarre issue while working Twine on my Firefox browser. Notably, the play and test buttons work once, but refuse to work at any point after that. The buttons act like they're being clicked, but they don't open the test/play tabs.

Some points I was asked:

  • I am only running one instance of Twine (and checked to make sure no other tabs were somehow interferring; this occurs even if I have nothing else open in Firefox)
  • I have no new extensions since this has cropped up
  • The only thing showing up in the console is "[vuex] already installed. Vue.use(Vuex) should be called only once."

I have no idea if it's relevant but I'm on Windows 10, on a laptop. I am online at the moment, it hasn't been tested offline.

@mcdemarco
Copy link

I got similar behavior in Firefox 66.0.3 (64-bit) on MacOS 10.12.6 (Sierra). Here's a screenshot of some more log info, including the Vuex warning mentioned by Callikat and some explicit errors I got when I kept trying. It's possible the content blocking warnings about cloudflare are causing the problem, e.g.,

Request to access cookie or storage on “https://cdnjs.cloudflare.com/ajax/libs/vuex/1.0.1/vuex.min.js” was blocked because we are blocking all third-party storage access requests and content blocking is enabled.

A screenshot of the console is attached.
firefox-error

@klembot
Copy link
Owner

klembot commented Apr 30, 2019

Hmm, I am not getting the same error on the same exact version of Firefox on MacOS. I do see the issue where hitting Play, closing the tab, and hitting Play again does nothing.

I'm wondering if this is a Firefox setting I don't have turned on, or something I turned off?

@mcdemarco
Copy link

Do you get the content blocking warnings but not the errors, or neither? I don’t remember setting up content blocking to try to unset it, but I can look around.

@klembot
Copy link
Owner

klembot commented May 1, 2019

I get neither right now.

@mcdemarco
Copy link

I turned off the content blocking (I had a custom setup for some reason, but even the "Strict" setup caused the warnings), which removed the content blocking warnings, but I still get the vuex already installed warning and the errors.

@mcdemarco
Copy link

I tried a few more things, some of them involving a local build of master, and was able to reproduce the play-once issue with a new story (in Firefox and Safari), and the play-reopens-the-story-list issue with a fresh import (of an old Sugarcube 2.20.0 story), in Firefox, Safari, and Chrome.

I didn't investigate the play-once issue, but the other issue seems to be happening in loadFormat() in story-format.js, where version is null and throws the error, and name is actually a local path on my machine: "/Users/mcd/.../sugarcube/SugarCube-2/"

Most, if not all, of the stories in my story list at the twinery are old imports, so I suspect the source of the problem is the same there, but I don't have an easy way to check that.

@klembot klembot added bug Something isn't working P2 (should) Usage is significantly impeded, enhancements to cover major functionality gaps labels May 4, 2019
@mcdemarco
Copy link

I noticed another instance of this behavior in the downloadable freestanding version of Twine 2.3.1. One of my old stories was set to use Paloma, but the story format list seems to have entirely reset itself to the current built-in story formats at some point, so Paloma was not found. Instead the story list window opened. The error on the console was:

twine.js:29 [vue-router] Uncaught error during transition: 
M @ twine.js:29
twine.js:29 Uncaught Error: No format is available named Paloma
    at loadFormat (twine.js:6)
    at VueComponent.ready (twine.js:23)
    at VueComponent.t._callHook (twine.js:6)
    at VueComponent.e (twine.js:6)
    at VueComponent.r (twine.js:6)
    at VueComponent.t.$emit (twine.js:6)
    at VueComponent.t._callHook (twine.js:6)
    at e (twine.js:6)
    at VueComponent.t.$before (twine.js:6)
    at twine.js:29

It seems like this error should be caught before the attempt to render the story. Even if the format really should have been around somewhere, accidents happen.

@klembot
Copy link
Owner

klembot commented Jun 3, 2019

Hmm... I tried adding Paloma to the web version and reloading, but the list seemed to stay stable. This is a stab in the dark, but maybe this specific issue was related to the version of Paloma changing but its URL did not? (Which is behavior that Twine should support, to be clear.)

@mcdemarco
Copy link

Hmm... I tried adding Paloma to the web version and reloading, but the list seemed to stay stable. This is a stab in the dark, but maybe this specific issue was related to the version of Paloma changing but its URL did not? (Which is behavior that Twine should support, to be clear.)

Yes, it's likely the version changed but the URL did not. Twine 2.2.1 is reporting the current version now, though, so I'm not sure how to check that more thoroughly.

@mcdemarco
Copy link

mcdemarco commented Jun 12, 2019

Here's a screenshot from the Firefox local storage inspector with the Twinery at 2.3.2, showing a local path to SugarCube rather than a normal story format name:

BadFormatNoCookie

(The open the story list once then fail to open behavior of both the test and play buttons is unchanged in this version.)

@klembot
Copy link
Owner

klembot commented Jun 12, 2019

That's definitely a bug, but I'm not sure at first glance how this could have happened.

@klembot
Copy link
Owner

klembot commented Jul 24, 2022

This looks like a bug with Twine 2.3 or earlier, and because of that I'm closing it. Please re-open or create a new issue if you find this is still a problem in 2.4.

@klembot klembot closed this as completed Jul 24, 2022
@mcdemarco
Copy link

This seems fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P2 (should) Usage is significantly impeded, enhancements to cover major functionality gaps
Projects
None yet
Development

No branches or pull requests

3 participants