1241250 - Prezi frozen at loading on fresh profile with latest Nightly 64 bits

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Charles Milette]

Attachment: Screenshot

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160120030239

Steps to reproduce:

1. Open Prezi editor (Flash needs to be installed)


Actual results:

Prezi froze at loading (See included picture)
In the picture, it is normal, but with educational Prezi, the same things happens


Expected results:

It should have loaded and worked

Comment 1

[Loic]

Reg range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d8e5f72da53aad99d4d4b67de44cb80f62754aa8&tochange=5d168ed7999b8f4c3472a822eddafd2b630870a5

Bob Owen — Bug 1185532: Turn on the NPAPI process sandbox for Windows 64-bit flash by default. r=bsmedberg

Comment 2

[Bob Owen (:bobowen)]

It looks like it is the effective removal of WinAuthenticatedUserSid by the USER_INTERACTIVE access token level in the sandbox policy that is causing this.

I'm not sure what flash is trying to do that is getting blocked, but I suspect it is some sort of network access.

bsmedberg - the regressions caused by our sandbox seem to be mounting up now.
Dropping the USER_INTERACTIVE access token level would not be as big a change as having to remove low integrity.
But ideally we'd want strengthen this setting (not weaken it) to USER_LIMITED to block read access to the user's home directory.
However this would definitely break flash file pickers even in windowless mode, unless we made changes to allow it, which might be possible.

Comment 3

[Benjamin Smedberg]

What information/decision do you need from me? It's true that we want to simultaneously tighten our sandbox and not regress user-visible cases like this.

We don't have any Windows logging that would tell us in detail what's being blocked here?

Comment 4

[Charles Milette]

I have the dollowing output in the console when loading, don't know if it may have something related:


11:53:55,568 L'utilisation de « getPreventDefault() » est obsolète. Utiliser « defaultPrevented » à la place. jquery-1.8.1.min.js:2:40212
11:53:57,655 cross-process JS call failed bootstrap.js:4063:0
11:53:57,655 [Private Tab] getTabPrivacyContext(): tab.linkedBrowser.contentWindow is null or not usable. Electrolysis?
Call stack:
privateTab.getTabPrivacyContext@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/Charles/AppData/Roaming/Mozilla/Firefox/Profiles/Charles/extensions/[e-mail]!/bootstrap.js:4072:27
privateTab.isPrivateTab@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/Charles/AppData/Roaming/Mozilla/Firefox/Profiles/Charles/extensions/[e-mail]!/bootstrap.js:4079:24
before@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/Charles/AppData/Roaming/Mozilla/Firefox/Profiles/Charles/extensions/[e-mail]!/bootstrap.js:1130:22
wrapper@chrome://privatetab/content/patcher.jsm:23:16
DOMLinkHandler.setIcon@chrome://browser/content/browser.js:3442:5
DOMLinkHandler.receiveMessage@chrome://browser/content/browser.js:3425:16
 bootstrap.js:4069:0
11:53:57,655 [Private Tab] isPrivateTab(): getTabPrivacyContext() failed. Electrolysis? bootstrap.js:4081:0
11:53:57,994 prezi-a.akamaihd.net : server does not support RFC 5746, see CVE-2009-3555 <inconnu>
11:53:58,443 TypeError: $(...).tooltip is not a function 75848a9a1b08.js:10:1400
11:53:58,748 mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create handsontable.full.js:18093:9
11:53:58,765 SyntaxError: missing ; before statement edit:147:65
11:53:58,871 TypeError: Prezi.data is undefined bd531f651e2a.js:6:128
11:54:01,976 "If you find digging around in stuff like this fun, you might want to take a look at our job page: http://prezi.com/jobs/ :)" edit

Comment 5

[Bob Owen (:bobowen)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)
> What information/decision do you need from me? It's true that we want to
> simultaneously tighten our sandbox and not regress user-visible cases like
> this.

Do we weaken the sandbox by moving back to USER_NON_ADMIN access level token from USER_INTERACTIVE?

This effectively means adding the Interactive and Authenticated Users SIDs back in and seems to fix a couple of the regressions, including this one.
We would still have low integrity in place.

I suppose all of this boils down to:

* Are the regressions bad enough to stop us pushing 64-bit further? - a question for product I guess
* If they are can we add policy rules or otherwise weaken the sandbox to fix, without completely compromising it? - this one is harder. Some thing like removing low integrity is a straight forward no. Losing USER_INTERACTIVE ... the honest answer is, I don't really know.
* If not is there something we and/or Adobe can do to fix the issue? - almost certainly, but I have no idea how long this would take.
 
> We don't have any Windows logging that would tell us in detail what's being
> blocked here?

We don't unfortunately.
We have logging when it is something (like file system access) that we can add policy rules for.

I'm not sure what logging can be turned on in Flash.

There is nothing native in Windows of which I know.
There are some tools I can try or plain old debugging, but trying to work out which of probably many function call failures is causing the issue can be fun.

Comment 6

[Bob Owen (:bobowen)]

I've found that there is a debugger version of Flash Player and this error appears to be causing the issue:

Error: Error #2014: Feature is not available at this time.
	at com.prezi.collab.union::SecureXMLSocket()
	at com.prezi.collab::MainReactorSprite()

It is there when the load fails, but not there when the sandbox is weakened and the load succeeds.

Comment 7

[Jim Mathies [:jimm]]

fallback is to use 32-bit fx.

Comment 8

[Chris Peterson [:cpeterson]]

This Flash sandbox bug should probably block wider testing of 64-bit Firefox because they break existing Flash content.

Comment 9

[Kalman Kemenczy]

Hey, my name is kalman, director of product at Prezi.

I have tried to reproduce the reported issue on different platforms (win32, win64, mac) and I had no issue loading prezi editor. I used  Nightly 51.

Could you help me reproduce the issue please?

Comment 10

[Bob Owen (:bobowen)]

(In reply to Kalman Kemenczy from comment #9)
> Hey, my name is kalman, director of product at Prezi.
> 
> I have tried to reproduce the reported issue on different platforms (win32,
> win64, mac) and I had no issue loading prezi editor. I used  Nightly 51.
> 
> Could you help me reproduce the issue please?

Hi, thanks for looking at this.

Did you use the 64-bit version of Nightly on win64?

Comment 11

[Kalman Kemenczy]

yes, on my win10 machine (and on my mac)
on the windows machine the build platform target is: x86_64-pc-mingw32

can you double check on your side if the problem is still there?

Comment 12

[Loic]

Attachment: ff51x64.jpg

I still have the issue with the latest Nightly x64, Flash x32 on Win 7 x64.

e10s on/off doesn't change anything.

Comment 13

[Charles Milette]

Afaik, only flash x64 can run on firefox x64

Comment 14

[Kalman Kemenczy]

ok, so your recommendation is to test on Win7 x64, right?
Unfortunately I only have Win7 x32 - where it runs well, but I will find a machine next week where I can test.

btw, why this is not an issue on win10 x64?

Comment 15

[Kalman Kemenczy]

we did another test on win8 x64 with Nightly 51 - we had no issues
how we can move forward from here?

Comment 16

[David Parks [:handyman]]

(In reply to Kalman Kemenczy from comment #14)
> ok, so your recommendation is to test on Win7 x64, right?
> Unfortunately I only have Win7 x32 - where it runs well, but I will find a
> machine next week where I can test.
> 
> btw, why this is not an issue on win10 x64?


Hey Kalman, I'm the engineer that initially reached out to you.  Huge thanks for taking this up.

I've tried the nightly build from the link I sent you... and also had success.  I'm not 100% sure yet why that is but I do see the failure in a build I know the origins of better -- here:

https://ftp.mozilla.org/pub/firefox/nightly/2016/09/2016-09-01-03-02-02-mozilla-central/firefox-51.0a1.en-US.win64.zip

This build reproduces the error when trying to load any Prezi.  I'm running Win10 x64 (the only version I tried) so there error is definitely there as well.  It fails with and without e10s active.  Give it a try and let me know if you get the same behavior.

Comment 17

[David Parks [:handyman]]

Meant to NI about comment 16.

Comment 18

[Kalman Kemenczy]

thanks David, using your link I can reproduce the issue. I will go back to the dev teams and we will see what we found (next week). stay tuned.

Comment 19

[Kalman Kemenczy]

hey David, we deployed a fix and works for me on our side.
can you double check, please?

Comment 20

[David Parks [:handyman]]

Hey Kalman,

I've had a chance to check this out a few different ways and unfortunately I'm still seeing the same error.  I've tried it with the nightly build I mentioned in comment 16 as well as the "latest" nightly build (from 9/9/16 -- which shouldn't be any different anyway).  I've tried refreshing the page in case there was a caching problem but still no luck.  I've even tried creating a fresh new profile to make sure there wasn't an issue with changed Firefox settings.  The only action I'm doing is editing a new Prezi.

Can you go back and take another look?

Comment 21

[Kalman Kemenczy]

Hey David,

Now I can reproduce again. Let me check it again on our side. Sorry for the false alarm.

Comment 22

[David Parks [:handyman]]

No worries.  If I can help from my end, feel free to ask.

When you do have something working, I'd really like to hear how your team went about it/if you have any suggestions for other flash plugin coders.

Comment 23

[Kalman Kemenczy]

Hey David,

We did some changes in our code and now we cannot reproduce the problem anymore.
May I ask you to double check at your side with clean install?

thanks
kalman

Comment 24

[Loic]

Indeed, I tested with the latest Nightly x64, freezing is gone when loading a new prezi.

Comment 25

[David Parks [:handyman]]

I'm unfortunately not having the same luck.  Here's what I've seen:

I am using this 9/20 x64 nightly:

https://ftp.mozilla.org/pub/firefox/nightly/2016/09/2016-09-20-03-04-29-mozilla-central/firefox-52.0a1.en-US.win64.zip

Once (the first try), I got the Prezi to successfully load.  However, it failed (with the same behavior as comment 0) on every page reload.  Also, when it did work, I still got the error message Bob reported in comment 6 -- I'm running the Flash debug plugin so it pops up in a log window.  It didn't seem to stop Prezi from working that first time, but it did appear.

It also continued to fail after a browser restart.

Then, I retried with a fresh profile.  This is initially successful.  This works through multiple page reloads.

Then I closed and reopened the nightly browser (again, with the new profile).  Now, every attempt fails, same as before.

One thing I can say that seems to be consistently different is that the spinner stalls at some early point ... but jumps ahead to a bit more than 50% filled after a mouse click.  I doubt that's useful though.

---

Can you try a new profile with that build to make sure we are talking about the same thing?

Comment 26

[Bob Owen (:bobowen)]

(In reply to David Parks [:handyman] from comment #25)
> I'm unfortunately not having the same luck.  Here's what I've seen:

I can still reproduce as well.

> Can you try a new profile with that build to make sure we are talking about
> the same thing?

If you are using a new profile, I think the important thing is that you test after you have restarted the browser.

Comment 27

[Kalman Kemenczy]

Thanks for the hint. We will continue the investigation.

Comment 28

[Kalman Kemenczy]

Dear all,

I installed several new machines in the last few days and created many profiles. I had no luck to reproduce the issue. And we double checked our code and we don't see where it would hang, because we have removed all suspicious part (or at least we think we did).

I am clueless at this point now. What you guys would suggest?
thanks

Comment 29

[David Parks [:handyman]]

Hi Kalman,

I'm still having no trouble seeing the error.  Sometimes, I have to restart the browser once for it to happen, sometimes not.  But it always eventually happens for me.

Can you tell me what steps you've tried to reproduce the failure?  Anything you can think of that might be diverging from that we are seeing could help.  Some basic issues include:

* What build are you using?  Where are you getting it from?  E.g. are you using the links to nightly I've posted or some other source?  If you aren't using a build directly posted to this bug, try that now.  The latest would be:

https://ftp.mozilla.org/pub/firefox/nightly/2016/09/2016-09-25-03-02-26-mozilla-central/firefox-52.0a1.en-US.win64.zip

Do not update the build once you run it (meaning: if the browser tells you an update is available, ignore it).

A minute ago, I was able to reproduce the error using this build with a new Firefox profile.

* What version of Windows are you using?  I'm not certain this matters but I am running Win10.

* Check if e10s is running in your browser.  Go to about:support and check under Application Basics for Multiprocess Windows.

...in fact, if you can just dump the info from about:support into this bug, that would be helpful.  (Just use the Copy Text To Clipboard button.)

* Is it possible that your plugin updates are being cached and served locally to you but haven't made it into distribution?

---

Some of these are very long shots but, as you point out, something confusing is going on.  If this doesn't bear fruit then I'm probably out of ideas as well.

Comment 30

[Kalman Kemenczy]

thanks for the hint. now i can reproduce it again.
what i did wrong is that I updated the nightly. we are working on it to find the root cause. 


btw, can you explain why should I use exactly this nightly build (instead of any of them)?

Comment 31

[David Parks [:handyman]]

Hey Kalman,

I'm not 100% sure whats going on but its not the expected behavior.  If you can just download and run one of the nightlys as a sanity check when things look fixed... that's the best suggestion I can make right now.  (It doesn't really matter if its the absolute latest build.)

FYI, to get the nightly links I've been posting:

* Go to https://nightly.mozilla.org/
* Click "Other nightly builds (FTP)" under "Other Resources"
* Navigate the folders for the current date (e.g. 2016, then 09)
* Choose the latest mozilla-central folder and pick the win64 .zip in it.

Happy hunting!

Comment 32

[Kalman Kemenczy]

Hey David,

Please try now. I cannot reproduce it now. I hope it will work on your side as well.

Comment 33

[David Parks [:handyman]]

I spent a bit of time playing around with the site and, yeah, everything looks great.  Thanks for helping clear out the x64 compatibility bugs!

Comment 34

[Kalman Kemenczy]

thank you all for the help.