QZ-Print fallback not working properly

[tresf]

@bberenz @robertcasto,

I've setup https://demo.qz.io but the applet fall-back logic seems to have a problem.

The error, which is expected is Websocket connection failed, however it should have a way to catch this and call deployQZApplet.

qzSocketError and qzNoConnection don't seem to be getting called either.

I'd like to add that this behaves slightly different between HTTP and HTTPS.

[robertcasto]

In what way?

On Sat, Jun 6, 2015 at 1:25 PM, Tres Finocchiaro notifications@github.com wrote:

I'd like to add that this behaves slightly different between HTTP and HTTPS.

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-109620586.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[tresf]

The ws:// insecure fall-back isn't allowed on HTTPS.

Here is a screenshot of it:

[tresf]

@robertcasto @bberenz do you have the capacity to look into this?

[robertcasto]

Yes, but not today. We will have to look at it tomorrow. I have today completely booked up.

On Tue, Jun 9, 2015 at 11:19 AM, Tres Finocchiaro notifications@github.com wrote:

@robertcasto https://github.com/robertcasto @bberenz https://github.com/bberenz do you have the capacity to look into this?

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-110399424.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[tresf]

@robertcasto just a friendly bump. :)

[robertcasto]

We got hit with a big Amazon problem yesterday. So I need to put you off until tomorrow. This is affecting us in a really bad way.

On Wed, Jun 10, 2015 at 1:21 PM, Tres Finocchiaro notifications@github.com wrote:

@robertcasto https://github.com/robertcasto just a friendly bump. :)

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-110842736.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[tresf]

@robertcasto any chance this can make it today? We're about ready for a 1.9.1 release.

[robertcasto]

I'll let you know. Got a big project to finish today so lots of things coming together at one time unfortunately.

Robert

On Fri, Jun 12, 2015 at 9:07 AM, Tres Finocchiaro notifications@github.com wrote:

@robertcasto https://github.com/robertcasto any chance this can make it today? We're about ready for a 1.9.1 release.

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-111485523.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[robertcasto]

Just spoke with Brett and he thinks it will be an easy thing to take care of this morning. You should see something later today.

On Fri, Jun 12, 2015 at 9:37 AM, Robert Casto casto.robert@gmail.com wrote:

I'll let you know. Got a big project to finish today so lots of things coming together at one time unfortunately.

Robert

On Fri, Jun 12, 2015 at 9:07 AM, Tres Finocchiaro < notifications@github.com> wrote:

@robertcasto https://github.com/robertcasto any chance this can make it today? We're about ready for a 1.9.1 release.

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-111485523.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[akberenz]

Should be addressed in 021411ddac1ab579aa90a21859435ad21adf65bc I've added a call to qzNoConnection when the javascript fails to create a websocket. And I've added code to attempt deploy of the applet inside of the sample's qzNoConnection function, just be sure to include the applet jars on the demo page.

[tresf]

Closed via 021411d

[tresf]

@bberenz this seems to fix fallback deployment on https://, but when I'm running the demo from the desktop (i.e. file:///) it doesn't seem to fallback properly. Can we take a second look at the fallback logic and make sure it works for all common scenarios?

[robertcasto]

Hi Tres,

Brett and I are heading to Seattle Sunday and will be there for the week. We will try to look at things as best we can, but our availability is going to be pretty limited.

Robert

On Sat, Jun 20, 2015 at 9:52 AM, Tres Finocchiaro notifications@github.com wrote:

@bberenz https://github.com/bberenz this seems to fix fallback deployment on https://, but when I'm running the demo from the desktop (i.e. file:///) it doesn't seem to fallback properly. Can we take a second look at the fallback logic and make sure it works for all common scenarios?

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-113770293.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[tresf]

Thanks for the FYI

[akberenz]

I am not able to replicate your issue. I get a successful connection to qz when running the sample from file:/// Are you getting any exceptions in the browser or java logs?

[tresf]

By fallback, I mean fallback to the Java Applet.

[akberenz]

In that case, it does not appear as though the demo included with the install has the applet files. I've changed the build script so they should be included in the socket directory as well now for fallback purposes (8d1b8bdbcfe592838090baa10866b783450766d6).

[tresf]

This is done intentionally. It's not hard to copy them there manually and you have a premium subscription for testing the trusted signed version. We won't be including this in our QZ Tray installer, please revert your commit.

[akberenz]

Apologies for that. Reverted at d62fb55320081ed2431a14f0f1a625a2eaa09c63. But if those files missing are the cause of your issues with fallback on file:/// then I believe we can close this issue.

[tresf]

Apologies for that. Reverted at d62fb55. But if those files missing are the cause of your issues with fallback on file:/// then I believe we can close this issue.

No, they are not the cause. Fallback doesn't work on file:/// (probably not on HTTP either).

@bberenz this seems to fix fallback deployment on https://, but when I'm running the demo from the desktop (i.e. file:///) it doesn't seem to fallback properly. Can we take a second look at the fallback logic and make sure it works for all common scenarios?

[akberenz]

Fallback to the applet from file:/// works for me. Can you post your environment & logs?

[tresf]

Thanks for testing. I'll attempt to reproduce again tonight.

[tresf]

Ok, I was able to reproduce the fallback failure on both file:/// as well as https:// on Safari. Here are the results:

Environment: OS: OSX 10.10 Browser: Safari 8.06 Logs: (The second error only displays on file:/// urls)

[Log] Starting deploy of qz (qz-websocket.js, line 32)
[Log] Attempting connection on port 8181 (qz-websocket.js, line 42)
[Error] WebSocket network error: The operation couldn’t be completed. Connection refused (sample.html, line 0)
[Error] Failed to load resource: The requested URL was not found on this server. (jquery-1.10.2.min.map, line 0)

[tresf]

FYI, all other browsers seem to be just fine. It appears the fallback is working on everything except for Safari. (Firefox on Windows and Mac are fine. Chrome on Windows and Mac are fine, IE is fine).

I updated the above post with the proper log including the debug info. Probably worth noting, Safari doesn't even appear to be falling back to 8282, 8383, etc, so it's likely something fundamental with the way the try/catch block is being handled in Safari.

[tresf]

@bberenz it looks like websocket.onclose is getting fired for Mac when the socket connection fails on Safari.

I tried this and it successfully calls deployQZApplet, but the document.write logic seems to be doing nothing on Apple now. The dom is getting updated with the proper <del> tags, but the applet won't load.

        websocket.onclose = function(event) {
            if (websocket.valid || qzConfig.portIndex >= qzConfig.ports.length) {
                qzSocketClose(event);
            }
            // ######## HERE ########
            if (!websocket.valid) {
                // Apple compat fix
                websocket.onerror();
            }
        };

[robertcasto]

@tres Could there be a permission problem? I know most browsers are getting away from Applets and have implemented security or turned them off. Perhaps that is what is happening here?

On Mon, Jun 29, 2015 at 11:55 PM, Tres Finocchiaro <notifications@github.com

wrote:

@bberenz https://github.com/bberenz it looks like websocket.onclose is getting fired for Mac when the socket connection fails on Safari.

I tried this and it successfully calls deployQZApplet, but the document.write logic seems to be doing nothing now. The dom is getting updated with the proper tags, but the applet won't load.

    websocket.onclose = function(event) {
        if (websocket.valid || qzConfig.portIndex >= qzConfig.ports.length) {
            qzSocketClose(event);
        }
        // ######## HERE ########
        if (!websocket.valid) {
            // Apple compat fix
            websocket.onerror();
        }
    };

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-116938075.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[tresf]

@robertcasto valid question... I've already allowed Java via https://qz.io/rawosx/#user-content-safari-settings and confirmed it works on Java's detection page.

This bug is two fold... the first part -- improper fallback -- is because WebSockets throws a different function on Safari when the socket fails per the websocket.onclose attempt above.

The second part I believe to be Safari ignoring the applet tags if they are appended after page load (which starts to illustrate why Oracle did this horrendous document.write stuff to begin with).

But in both cases, the introduction of QZ Tray prevents the applet from loading on that browser with our default sample.html, which we should fix. :)

[robertcasto]

So are you suggesting we do the horrendous document.write option?

On Tue, Jun 30, 2015 at 11:00 AM, Tres Finocchiaro <notifications@github.com

wrote:

@robertcasto https://github.com/robertcasto valid question... I've already allowed Java via https://qz.io/rawosx/#user-content-safari-settings and confirmed it works on Java's detection page.

This bug is two fold... the first part -- improper fallback -- is because WebSockets throws a different function on Safari when the socket fails per the websocket.onclose attempt above.

The second part I believe to be Safari ignoring the applet tags if they are appended after page load (which starts to illustrate why Oracle did this horrendous document.write stuff to begin with).

But in both cases, the introduction of QZ Tray prevents the applet from loading on that browser with our default sample.html, which we should fix. :)

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/34#issuecomment-117219124.

[image: SellersToolbox Website] http://www.sellerstoolbox.com Robert Casto (owner) Tools for Amazon Sellers p: 1-513-847-4942 c: 1-513-886-1550 e: casto.robert@gmail.com

[tresf]

So are you suggesting we do the horrendous document.write option?

No because we try QZ Tray first, so it's too late. Brett's approach is the right approach, but I still feel we need to exhaust our options on both issues.