search

ruffle-rs / ruffle

A Flash Player emulator written in Rust
https://ruffle.rs
Other
15.41k stars 798 forks source link

FSCommand tracking issue #65

Open RePod opened 4 years ago

RePod commented 4 years ago

Side effect of #54

getURL calls to fscommand are treated like regular URLs and go through a browser's regular handling and manifest as a popup leading nowhere. This is very noticeable when testing on web.

Examples:

In a situation where these fire repeatedly under normal conditions (such as frames looping during a preloader), they spam requests or popups using web.

Some quick googling reveals there's also a more proper accompanying function.

Herschel commented 4 years ago

Looks like fscommand gets compiled into a getURL("fscommand:x");. For now, we should check for the fscommand scheme in the URL and just ignore it.

Most of the fscommand properties had better alternatives later, so we can hook them up as we implement them. Here's a list: image

None of the above properties worked in the web player anyway AFAIK (need testing). However, in the web player, you could fire JavaScript events using fscommand (depending on the allowScriptAccess flag on the embed).

kmeisthax commented 4 years ago

Whipped up a very primitive PoC to stop throwing up popups during my lunch hour on my avm-fscommand branch. Will look into implementing those commands later tonight.

kmeisthax commented 4 years ago

Okay, so it turns out the GetURL2 function also needs to parse FSCommands, so I updated avm-fscommand to also do that. Right now it just fires off a warning about an unimplemented command, and I don't see any point in implementing any of those straight away. I can send a PR if you want to merge this in.

The link you sent scares me, though. Apparently there were at least two or three additional SWF environments that used FSCommands to extend the Flash VM in all sorts of weird, hacky ways? I need to do more research on these Flash para-environments sometime...

Herschel commented 4 years ago

Merged in @kmeisthax changes in b385522 to ignore fscommands for now.

adrian17 commented 3 years ago

Looks like there are some pre-MX obscure FSCommands used in same games too. For example, Arcane: The Miller Estate uses getUrl("FSCommand:save", "1"); and similarly load (which apparently were already considered obscure in 2001: https://board.flashkit.com/board/showthread.php?185102-FSCOmmand-SAVE , https://board.flashkit.com/board/showthread.php?291885-fscommand-save-still-working-in-mx ) and where, which I wasn't able to research at all. (unless I misunderstood something here)

Toad06 commented 2 years ago

The Steppenwolf games also use the save and load commands. When these commands are called, Flash Player tries to execute a JavaScript function named nnn_DoFSCommand, where "nnn" is the value of the name attribute in the HTML embed. The arguments match the ones provided in Flash.

Here's a sample: fscommand_save_load_sample.zip Original URL: http://steppenwolf.epizy.com/steppenwolf/play.jsp?episode=episode15

EDIT: Actually it looks like the command names don't matter in the web player and the *_DoFSCommand function will always be called (if it exists), even on in-built commands ("quit", showmenu", etc. - but these commands won't do anything else, as Mike pointed out). Here's another sample: fscommand_sample.zip

sombraguerrero commented 2 years ago

So, just polling for opinion here more than anything else. Is the consensus that we just don't want to deal with fscommands at all until we have the "paraenvironments" and all the hacky fringe cases figured out? Or would it be okay to implement the "standard" ones we know about? I was thinking we could at least do fullscreen.

Lord-McSweeney commented 11 months ago

Note- we still haven't implemented the [value of the "name" attribute]_DoFSCommand functionality, #4527 and #3588 need it- they calls Captivate_DoFSCommand(...)