VMware Horizon Community
hunterok
Enthusiast
Enthusiast

Firefox 57 Quantum problem

VMware Horizon 7.3.1 + Instant Clones Windows 10 LTSB (1607 14393.1884) + App Volumes 2.13.1 Writable Volume (template_uia_plus_profile.vmdk (2.12.1.39)

We have a strange problem with non-admin users using Firefox 57 (installed by users themselves as user app). When they open https sites they have such error

mQt4Rir.png

Also F12 Developer Tools don't work and show just blank panel. Google Chrome works without any problems

Any Ideas?

15 Replies
batuhandemirdal
Enthusiast
Enthusiast

Hi,

57.0.1. There is no problem in version. If you remove and re-install, I believe the problem will be solved.ebay.png

0 Kudos
hunterok
Enthusiast
Enthusiast

57.02 - the same problem. I think this is something with user/admin rights as admin users don't have such problem.

Mark808
Enthusiast
Enthusiast

I have the issue where FF 57.01 and 57.0.2 (64 bit) will only print blank pages.  Other windows application including Edge are able to successfully print.

Anyone else seeing this and/or have a recommended fix or work around?

VMware Horizon 7.1.0 + Instant Clones Windows 10 + App Volumes 2.13.1 Writable Volume (template_uia_plus_profile.vmdk (2.13.0.23)

0 Kudos
Sravan_k
Expert
Expert

I request you to re-install your application "Run as administrator" and test it [do the latest version 57.0.2]

On F12 tools, please check either the below windows service is running are not

"Microsoft (R) Diagnostics Hub Standard Collector Service"

Please provide me your feedback

Regards,

Vkmr.

Skmr
Enthusiast
Enthusiast

I don't know about the security question but on F12 tools issue, I do experianced same problem as you are facing on IE, my resolution is enabling the service [Microsoft (R) Diagnostics Hub Standard Collector Service] that Vkmr mentioned.

hope solution will fix your issue as well...

Thank you,

Pere.

0 Kudos
DPurscell
Contributor
Contributor

I was experiencing the same issue.   When running Firefox Quantum (57.0.4) normally and connecting to View Admin, it would spike the CPU to >97%.   Chrome didn't have the same problem, but the problem was repeatable with Firefox..

Based on the notes here, I opened Firefox with Run as Admin and connected to View Admin.  The CPU remained normal. 

I then tried to duplicate the original problem and have been unable to make it fail since.

Ever since I opened Firefox as admin and connected to View Admin, Firefox has been responding normally with View Admin.

Go figure.

hunterok
Enthusiast
Enthusiast

I request you to re-install your application "Run as administrator" and test it [do the latest version 57.0.2]

non-admin users can't use "Run as administrator"

0 Kudos
Sravan_k
Expert
Expert

Yes, I am aware of it

what I mean is if we install/capture application/appstack as "Run as administrator" is recommended and I am asking it as part of troubleshooting.

By the way, if your are using UEM 9.2, 9.2.1 or 9.3, you can control applications to run as administrators/ privilege mode

Thank you,

Vkmr.    

Skmr
Enthusiast
Enthusiast

On UEM privilege access, I am taking advantage of this feature too extent as we are having really old old applications some of them are on-site applications

Regards,

Pere

0 Kudos
VMvvol
Enthusiast
Enthusiast

Hi,

I have the same problem but I got it fixed by using one of the Firefox plug-in which is related to printing, I did not remember the plug-in name but will update here if I come across

Regards,

Volga.

0 Kudos
rdonohue
Enthusiast
Enthusiast

I just sent the message below to support. Glad to know I'm not the only one experiencing issue with firefox with writable volumes attached.

Just an update, I’m noticing other strange behavior in these vm’s with App Volumes attached. The most noticeable issues are with Firefox. I’ve tested it three ways. Installing firefox on the golden image, deploying firefox in an appstack, and having the user install it in a writable volume. If the user is a local administrator on the vm everything seems to work fine. If the user is not an administrator firefox goes nuts. Each time you log out and log back in and try it it seems to have different symptoms. Trying with the same user on the same machine with appstacks and writable volumes detached it works fine.

Examples of the symptoms. These symptoms change between logins:

  • When opening firefox the user gets a message that says the about:newtab page either couldn’t be found or access denied.
  • When opening firefox it opens two separate windows. Both windows are blank and entering a url doesn’t do anything. Clicking the X in the top right of the window doesn’t do anything. Hovering over the icon in the taskbar and clicking the X there does close the windows, but the firefox process continues running and won’t let you reopen firefox until you kill the process. It will keep doing this until you logout and log back in.
  • Cannot install addons. Get a message saying access denied. Sometimes the same user is able to install the addon, so does not seem to actually be a permissions issue.
  • Once addons are installed data stored in the addon is not persistent when closing and opening firefox. For example, if I install the Lastpass addon and login and tell it to remember my username and password it will work. But if I close firefox and reopen it my username and password disappear. On sessions where the user is an admin, or if it’s a regular user without app volumes attached, Lastpass will stay logged in.

Since the behavior seems to happen regardless of how the app is installed I’m assuming this is an issue with the writable volume.

0 Kudos
rdonohue
Enthusiast
Enthusiast

I tried downgrading to 56 and firefox seems to be more stable. I still see the issue where it loses information in addons. Like losing my username and password for Lastpass after restarting the browser. The strange thing is that this isn't the case for everyone. One of the guys working on this issue with me was having some of the same problems, but after leaving it sitting for a while and several reboots, everything is working fine for him now running on 58. So it seems to be a very sporadic issue. I'm curious if it's somehow related to this issue: AV 2.13.1: Can no longer see C:\SnapVolumesTemp after updating to 2.13.1

0 Kudos
rdonohue
Enthusiast
Enthusiast

That does appear to be the issue. It seems to happen randomly though, and in some instances goes away on its own. This is what I've found fixes it, though I haven't thoroughly tested it. I suspect that it is affecting other applications as well.

In firefox go to about:profiles

If your profile starts with C:\SnapVolumesTemp then you need to create a new profile. When you create the new profile make sure it points to the default location that should start with C:\Users\

Set the new profile to default. Restart Firefox. Go back to about:profiles and delete the old profile. You should be good to go. It seems that when it's pointing to that other location it creates all sorts of unusual behavior.

rdonohue
Enthusiast
Enthusiast

This doesn't seem to be a permanent fix. It does indicate to me though that the missing C:\SnapVolumesTemp path is what is causing these issues though.

0 Kudos
hunterok
Enthusiast
Enthusiast

Thanks for your tests and for sharing a probable fix. I'll try to run this installation variants in my environment.

0 Kudos