IPP-Everywhere printer service names rejected in zeroconf_printer_detector |
||
Issue descriptionThis code: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/printing/zeroconf_printer_detector.cc?rcl=18e10dc0198757b62a80bd8d32ce4dc88eacd109&l=143 lacks handlers for the kIpp[s]EverywhereServiceName cases. Thus, even though we're listening for the Ipp Everywhere services, we will reject any records found when we go to convert them to Printer structures. Noticed on inspection looking for a different bug.
,
Jan 29 2018
Yup. We would miss out on the logic that marks them as autoconf-capable, but probably still be able to set them up correctly via the normal flow.
,
Jan 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/da41f9b5aa6efe2305db64da952a220a11c16253 commit da41f9b5aa6efe2305db64da952a220a11c16253 Author: Justin Carlson <justincarlson@chromium.org> Date: Mon Jan 29 20:45:31 2018 Fix a IPP-E bug in zeroconf printer detector. When converting from the mDNS service information to a DetectedPrinter struct, we fail with an IPP-E service name because we forgot to check for them. This fixes that. Bug: 806390 Change-Id: Iad2853f458ac3880f9d62f45e135ecb16ee942b8 Reviewed-on: https://chromium-review.googlesource.com/890046 Reviewed-by: Sean Kau <skau@chromium.org> Commit-Queue: Justin Carlson <justincarlson@chromium.org> Cr-Commit-Position: refs/heads/master@{#532576} [modify] https://crrev.com/da41f9b5aa6efe2305db64da952a220a11c16253/chrome/browser/chromeos/printing/zeroconf_printer_detector.cc
,
Jan 31 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by skau@chromium.org
, Jan 29 2018Labels: OS-Chrome