Closed tresf closed 7 years ago
Hello Tres,
We are also experiencing this issue. Please let me know if I can be of any help.
The Firefox team is calling this a "regression" so it appears to be a bug with Firefox 54. Here are the details: https://bugzilla.mozilla.org/show_bug.cgi?id=1373791.
Here's a stackoverflow question explaining the problem: https://stackoverflow.com/questions/44550970
We can script adding the HTTPS exception inside a new installer but it is a lot of work and will only work if QZ Tray is running.
Another option is for us to switch our self-signed certificate to a full CA-SSL chain, which is overkill for SSL back to localhost. We're still weighing our options. In the mean time, if the Firefox team comes back with anything we'll post it here.
Another option is for us to switch our self-signed certificate to a full CA-SSL chain
This appears to be our only option.
Windows and MacOS betas available here
Work is 75% completed and is on the firefox
branch.
Windows and MacOS beta installers are available here: https://github.com/tresf/tray/releases/tag/v2.0.3-4
Update: I've applied digital signatures to the Windows and Mac installers so that they'll install without security warnings.
Using QZ Tray 2.0.4-1 in MacOS SIERRA 10.12.6 (16G29)
Hi I’m currently using Firefox 55.0.3 (64-bits) and it presents the same problem described here
If I follow the workaround described It will work fine.
This doesn’t happen in Windows 10 Firefox (It works fine)
@Itaqua I just tested QZ Tray 2.0.4-1 with Firefox 55.0.3 on MacOS 10.12.6 and did not experience the problem.
Is there a chance you have another copy of Firefox on the system? We use a program called lsregister
to locate the Firefox install location, but MacOS will register Firefox.app
in any location, such as dragging it to the Desktop, etc. We try to filter out false-positives (e.g. DMG mount point, Recycling Bin) but there may be some we have missed.
What is the output of the following command?
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump |grep /Firefox.app$
Hi thanks for answering, the output of is:
❯❯❯/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump |grep /Firefox.app$
path: /Users/octavio/Applications (Parallels)/{d3922dbc-487d-4657-bee7-b4dde14b5550} Applications.localized/Firefox.app
path: /Users/octavio/Applications (Parallels)/{c33993be-0a52-4464-9944-adcfe42a4758} Applications.localized/Firefox.app
path: /Users/octavio/Applications (Parallels)/{8d3c1b5c-1d3c-457c-864f-3aa372645039} Applications.localized/Firefox.app
path: /Applications/Firefox.app
Firefox in the Parallels VM (Windows 10) is working fine Our QA is presenting the same behavior in FF on macOS
So Parallels has published the Windows version of Firefox and irresponsibly chosen the same application name that Firefox uses. They shouldn't have done this, but we can code an exception into our installer to omit this as well. I would not consider this common for the Mac desktops we support, but if Parallels is going to push the seamless win32 integration, we'll have to hack around it.
@Itaqua I'm moving discussion to #240, as this is a separate issue to the original bug report here.
I'm experiencing something that seems similar to this on Firefox 95 beta 12 currently. The stable release (94) does not appear to have this issue.
Console reports Firefox can’t establish a connection to the server at wss://localhost:8181/.
Opening https://localhost:8181/
brings up the Warning: Potential Security Risk Ahead
page.
I'm experiencing something that seems similar to this on Firefox 95 beta 12 currently. The stable release (94) does not appear to have this issue.
I tested with Firefox 95 Beta 12, Firefox 95 Beta 0, Firefox Developer Edition 95 Beta 12, none exhibit the issue on my machine. Since this issue title is about Firefox 54, please open and cross-link a new bug report including a screenshot of the certificate you're getting from https://localhost:8181 and detailed steps to reproduce including QZ Tray version, OS version and any other details necessary to reproduce your environment.
After several reports, we've identified that Firefox 54 no longer accepts our self-signed SSL certificate.
We've tried several things already such as resetting Firefox, enabling/disabling the
CA Cert
flag, addingKeyUsage
andExtendedKeyUsage
flags to no avail. (e.g.keytool ... -ext ku:critical=digitalSignature,keyEncipherment -ext eku=serverAuth,clientAuth -ext bc:critical=ca:false
)The symptom look like this:
A temporary workaround is to click https://localhost:8181 and add the certificate exception, then return back to the originating page.
We have reached out to our Firefox consultant to see if there is a way we can patch our installer to fix this.