Closed tresf closed 9 years ago
I'm guessing that there could be a character in the name that we are not handling properly.
On Mon, Jun 1, 2015 at 12:59 PM, Tres Finocchiaro notifications@github.com wrote:
@robertcasto https://github.com/robertcasto @bberenz https://github.com/bberenz I'm not sure what causes this, but want to open a placholder for it. The bug submitter claims this does not occur with the applet version (assuming they are using 1.8 branch for the applet as we haven't released any 1.9 branch versions).
[image: unnamed] https://cloud.githubusercontent.com/assets/6345473/7918242/d95bc072-085d-11e5-92c2-95ede7ea3bc9.png
Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/31.
[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 I'm pretty sure this is a bug. I just tried the button all by itself and it won't work with a standard printer name on my PC either. Must have been a button I missed in early testing.
@robertcasto your suspicions are correct... It appears the windows UNC path may be part of the cause, most likely the double blackslash \\
Zebra LP2844 # <---- THIS WORKS
\\Server\Zebra LP2844 # <---- THIS DOESN'T WORK
Edit, here's the log:
INFO: Server frame: TEXT[len=92,fin=true,rsv=...,masked=true]
Jun 01, 2015 8:24:07 PM qz.ws.PrintSocket onMessage
INFO: Request: undefined{"method":"findPrinter","params":["zebra"],"callback":"qzDoneFinding","init":false}
Jun 01, 2015 8:24:07 PM qz.auth.Certificate isSignatureValid
WARNING: Signature length not correct: got 6 but was expecting 256
Jun 01, 2015 8:24:07 PM qz.ws.PrintSocket processMessage
INFO: Server message: {"method":"findPrinter","params":["zebra"],"callback":"qzDoneFinding","init":false}
Jun 01, 2015 8:24:08 PM qz.common.TrayManager showGatewayDialog
INFO: Allowed An anonymous request to access local resources
Jun 01, 2015 8:24:08 PM qz.ws.PrintSocket convertType
INFO: CONVERTING zebra --> class java.lang.String
Jun 01, 2015 8:24:08 PM qz.ws.PrintSocket processMessage
INFO: Calling: findPrinter[zebra]
Jun 01, 2015 8:24:08 PM qz.PrintFunction findPrinter
INFO: ===== SEARCHING FOR PRINTER =====
Jun 01, 2015 8:24:08 PM qz.printer.PrintServiceMatcher getPrinterArray
INFO: Found 5 printers
Jun 01, 2015 8:24:09 PM qz.printer.PrintServiceMatcher findPrinter
INFO: Found 5 attached printers.
Jun 01, 2015 8:24:09 PM qz.printer.PrintServiceMatcher findPrinter
INFO: Printer specified: \Qzebra\E
Jun 01, 2015 8:24:09 PM qz.printer.PrintServiceMatcher findPrinter
INFO: Printer name match: \\win7vm\Zebra LP2844
Jun 01, 2015 8:24:09 PM qz.printer.PrintServiceMatcher findPrinter
INFO: Using best match: \\win7vm\Zebra LP2844
Jun 01, 2015 8:24:09 PM qz.PrintRaw clear
INFO: Print buffer has been cleared.
Jun 01, 2015 8:24:09 PM qz.ws.PrintSocket processMessage
INFO: Selected New Printer
Jun 01, 2015 8:24:09 PM qz.ws.PrintSocket sendResponse
INFO: Response: {"method":"getPrinter","params":[],"callback":"setupMethods","init":true,"result":"\\win7vm\Zebra LP2844"}
Jun 01, 2015 8:24:09 PM qz.ws.PrintSocket sendResponse
INFO: Response: {"method":"getPrinters","params":[],"callback":"setupMethods","init":true,"result":"xebra LP2844,Microsoft XPS Document Writer,Fax,Epson TM88V,%5C%5Cwin7vm%5CZebra LP2844"}
Jun 01, 2015 8:24:09 PM qz.ws.PrintSocket sendResponse
INFO: Response: {"method":"findPrinter","params":["zebra"],"callback":"qzDoneFinding","init":false,"result":"void"}
Ok... I'm confused... I'm looking at PrintSocket.java
around line 324 and I'm seeing this... is this a typo? Wouldn't this evaluate twice? The latter seems to try to do some escaping but I'm a bit confused about the approach.
Also, I would expect all method calls which could suffer this bug be escaped. Could the serial functionality suffer this same bug?
// Send new return value for getPrinter when selected printer changes
if ("findPrinter".equals(name)) {
log.info("Selected New Printer");
sendNewMethod(session, "getPrinter", qz.getPrinter());
}
if ("findPrinter".equals(name) || "findPrinters".equals(name)) {
sendNewMethod(session, "getPrinters", qz.getPrinters().replaceAll("\\\\", "%5C")); //escape all backslashes
}
Edit: Committed the patch for now. Interested to know the explanation for this.
Did you find a solution and that is why this is closed?
On Mon, Jun 1, 2015 at 8:49 PM, Tres Finocchiaro notifications@github.com wrote:
Closed #31 https://github.com/qzind/qz-print/issues/31 via f085e04 https://github.com/qzind/qz-print/commit/f085e04a09a63f0ea3b226af8871b9de12822ed2 .
Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/31#event-319514662.
[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
Yes, but still interested in Brett's answers. Commit f085e04 closes this. I just mirrored his technique, but I'm a bit confused as to the approach (not the backslash part, but rather the multiple findPrinter.equals()
statements).
The two if statements each send a different method. When findPrinter
is called we set the current printer and send the result of the getPrinter
method. When either findPrinter
or findPrinters
is called, we now have a list of available printers (but might not have set a printer), so we send the result of the getPrinters
method.
Thanks. What about the escaping question... can other functions suffer this same bug?
It's possible, in which case it'll probably be best to just catch all strings going through the sendNewMethod
call and escape them.
It's possible, in which case it'll probably be best to just catch all strings going through the sendNewMethod call and escape them.
Thanks. Should I open a new bug report to keep track of this or do you expect to tackle that right away?
I can take care of it now, should be quick.
Great, thanks.
da7215a4c5830e5d97d672e49c24e215b81ae5f6
:+1:
@robertcasto @bberenz I'm not sure what causes this, but want to open a placholder for it. The bug submitter claims this does not occur with the applet version (assuming they are using 1.8 branch for the applet as we haven't released any 1.9 branch versions).