Closed Bug 1513966 Opened 11 months ago Closed 10 months ago

Flash Player Error #2130: Unable to flush SharedObject.

Categories

(Core :: Security: Process Sandboxing, defect, P1)

64 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1514073
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- fixed
firefox67 --- fixed

People

(Reporter: valentin.radoi, Assigned: handyman)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Loaded our SWF into Firefox Quantum 64.0 and when the AS3 code tried to use SharedObject.flush() API to save a Local Shared Object on disk (equivalent of a cookie for Flash Player https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/SharedObject.html), it has thrown an "Error #2130: Unable to flush SharedObject" and nothing was saved.

Happens to all of our games that use SharedObjects, across many computers. We also confirmed it with a simple test app that tries to write down just a single short string.

Flash Player Settings Manager (https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html) can't save its configuration changes either i.e. they are not persistent.

Happens only with Firefox 64.0, previous version was working fine. We have Flash Player 32 installed in Firefox.


Actual results:

Flash Player throws this error: "Error #2130: Unable to flush SharedObject" and the content is not saved to disk. However, an empty folder is created for the app/site in question under C:\Users\username\AppData\Roaming\Macromedia\Flash Player\#SharedObjects\... but no file is created under that folder.


Expected results:

The flushing of the SharedObject should have been successful and the data should appear on disk at the designated location for SharedObjects and be retrievable later.
The Flash player settings problem seems to be a different issue at least with the 64bit plugin because this is should be already broken in Firefox63. I created bug 1514073 for that problem.

Do you have a public example URL where I can test the SharedObject bug ?
Does it work again if you open about:config, confirm the warning, enter "sandbox" in the top filter bar and change dom.ipc.plugins.sandbox-level.flash from "3" to "0" and restart Firefox ?

Please do not forget to switch that setting back to "3" after your test.

bug 1513477 could be related to this report.
Flags: needinfo?(valentin.radoi)
Yes, changing dom.ipc.plugins.sandbox-level.flash from "3" to "0" does fix the issue and the Shared Object is written on disk with no error. The interesting part is that after changing it from "0" back to "3" and restarting Firefox, it still works. So right now I can't make it happen again, although it was clearly happening with the same SWF before I messed with the dom.ipc.plugins.sandbox-level.flash parameter.

I've prepared a small test app for you here https://pphx.devqublixaws.com/so/SharedObjectTester.html
If you can read "Local Shared Object written successfully!" it means no errors was thrown and it works. Otherwise it will say "ERROR: Failed to write Local Shared Object!" and the Error #2130: Unable to flush SharedObject will be thrown, but in order to see it you'll need Flash Player Debugger version from here https://www.adobe.com/support/flashplayer/debug_downloads.html.

You can download the code for that little test app from here https://pphx.devqublixaws.com/so/SharedObjectTester.as, if you want to make your own SWF build.

PS: I've logged this issue yesterday with Adobe as well, in case there is anything they can do on their side with Flash Player, in order to help https://tracker.adobe.com/#/view/FP-4198954.
Flags: needinfo?(valentin.radoi)
Thank you very much for the testcase.


This is the regression range for the testcase https://pphx.devqublixaws.com/so/SharedObjectTester.html 
> 3:22.26 INFO: No more inbound revisions, bisection finished.
> 3:22.26 INFO: Last good revision: ba708fde30b8f8d2ae4d1febfa2e88e2c1bf1cc4
> 3:22.26 INFO: First bad revision: a910482f4598931944910a357431b22f823578fb
> 3:22.26 INFO: Pushlog:
>https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ba708fde30b8f8d2ae4d1febfa2e88e2c1bf1cc4&tochange=a910482f4598931944910a357431b22f823578fb

David Parks — Bug 1366256 - Part 1: Promote Windows plugin process sandbox to level 3. r=bobowen


This is the same regression range as bug 1514073 and that bug should probably duped to this one.
Status: UNCONFIRMED → NEW
Component: Untriaged → Security: Process Sandboxing
Ever confirmed: true
Flags: needinfo?(davidp99)
Keywords: regression
Product: Firefox → Core
Assignee: nobody → davidp99
Flags: needinfo?(davidp99)
Priority: -- → P1
Duplicate of this bug: 1514889

64=affected according to the reporter in comment 0

My understanding is we're not going to have another 64 dot release given the impending 65 release.

Duplicate of this bug: 1523929

I've got a fix for bug 1514073 and it looks like it fixes this issue as well so I'm duping it over.

Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1514073
You need to log in before you can comment on or make changes to this bug.