web: Resolve URLs without a protocol in the extension player and improve error messages #16913
Conversation
|
hello Korne, |
|
Hey :) |
| @@ -42,9 +42,12 @@ error-wasm-mime-type = | |||
| error-invalid-swf = | |||
| Ruffle cannot parse the requested file. | |||
| The most likely reason is that the requested file is not a valid SWF. | |||
| error-swf-fetch = | |||
| error-swf-fetch-v2 = | |||
There was a problem hiding this comment.
Why the addition of the -v2? Crowdin will throw out all the old translations regardless, and if you're not also keeping error-swf-fetch as a separate translation string I don't see a reason to change this key.
There was a problem hiding this comment.
Crowdin will throw out all the old translations regardless
Huh? I didn't know that. That's actually not really good because this is utilising a core Fluent feature: The separation of minor changes that don't affect translations and major changes that do affect them:
Fluent's use of unique identifiers allows for at least two of those three states to remain separated - minor changes may be applied and if the developer does not alter the unique identifier (a.k.a does not change the social contract), all translations remain valid. On the other hand if the developer changes the ID, all translations become invalid and must be updated.
I wish Fluent would have implemented the idea of message versioning they're investigating as a third option because this is the ideal case in which this would be used (as old translations are still better than none, but should be marked as outdated and updated eventually). However, the related issue hasn't been updated in years :/ I might try to get it more attention again in the future.
"The url blabla test is no valid url" |
|
Hmm, I would have thought that both is valid tbh, although the second one is probably better. |
|
amittedly its a nitpick 😅 |
Korne127
force-pushed
the
resolve-extension-player-urls
branch
from
699e67a
to
86352c1
Compare
|
@Croworbit Don't worry, I really appreciate it! Especially the things that I overlooked myself are good to know :) |
| } | ||
|
|
||
| try { | ||
| // Only use http if it works but https doesn't |
There was a problem hiding this comment.
I am not totally convinced that we shouldn't just default to https:
There was a problem hiding this comment.
That's because HTTP website cannot fetch HTTPS resources, and vice versa.
There was a problem hiding this comment.
How is this relevant? The "page" fetching this is our extension.
There was a problem hiding this comment.
Oh, then that won't be a problem.
There was a problem hiding this comment.
But what if the website only supports http and not https.
There was a problem hiding this comment.
I thought about that for a longer time too. But Ruffle is used to play Flash games, mostly legacy content. Old SWF files are especially likely to be hosted on outdated websites which don't support HTTPS yet.
And if the website uses HTTPS, that's just used. HTTP is only used if it's the websites only supports it, but not HTTPS.
Previously, only URLs explicitly including the web protocol (HTTPS or HTTP) in the beginning could be resolved in the extension player. This has been changed. The extension player now resolves URLs without a protocol and adds https:// or http:// if the URL is likely a valid web URL and file:/// if the URL is a valid file URL. HTTP is only used if the server only supports HTTP and not HTTPS.
Previously, the Ruffle player had shown an incorrect error message if the entered URL wasn't a valid web URL. This has been fixed and improved. Three new error messages have been added for this case: One in case the entered URL is a local file URL, one in case the entered URL uses a different protocol than https, http or file and one in case the entered URL isn't a valid URL for any protocol at all. Additionally, the error message in case Ruffle couldn't load the SWF file (using a valid web URL) has been improved to also include the tip that the HTTP protocol should be (explicitly) used for websites that don't support HTTPS.
Previously, when entering a URL in the extension player, it had been resolved before creating a RufflePlayer instance and displaying a loading screen. As resolving can include testing for server availability (to decide whether HTTPS or HTTP is used), this could create a wait time without the loading screen. This has been fixed. The URL is now resolved while the loading screen is displayed. Additionally, the timeouts have been increased (they were low because of the lack of a loading animation). A bug that caused the document title to not be set correctly if the SWF URL was the main page of a domain has also been fixed.
Korne127
force-pushed
the
resolve-extension-player-urls
branch
from
86352c1
to
1621c78
Compare
Currently, only URLs explicitly including the web protocol (HTTPS or HTTP) in the beginning can be resolved in the extension player. Additionally, if the URL doesn't include the HTTPS or HTTP protocol in the beginning, a wrong error is displayed. It states that the user ran Ruffle on the file: protocol which is wrong and confusing:
This pull request fixes this.
With this pull request, the extension player resolves URLs without a protocol. It adds https:// or http:// if the URL is likely a valid web URL and file:/// if the URL is a valid file URL.
To determine whether HTTPS or HTTP should be used, Ruffle tests whether the server supports HTTPS. HTTP is only used if the server only supports HTTP and not HTTPS. This test happens while the loading screen is displayed.
This means that the user can now enter URLs without a leading https:// like you (usually) do in the browser.
Additionally, this pull request fixes and improves the error behaviour if the URL can't be resolved or used.
Instead of the wrong error, one of four more specific errors will be displayed:
That error has also been modified to also include the tip that the HTTP protocol should be (explicitly) used for websites that don't support HTTPS:
Also, a bug that caused the document title to not be set correctly if the SWF URL was the main page of a domain has been fixed. The handling of setting the document title of the extension player has generally been made more consistent.