New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 750386 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Failed PPDs are being cached in PPDCache

Project Member Reported by skau@chromium.org, Jul 28 2017

Issue description

Chrome Version: 62.0.3167.0
OS: ChromeOS

What steps will reproduce the problem?
(1) Find a broken PPD file
(2) Attempt to add printer with PPD file
(3) Fix PPD file (editing the contents)
(4) Add printer with PPD file

What is the expected result?
Printer is added successfully

What happens instead?
Adding the printer still fails

What is happening?
The PPD is being saved in PPDCache the first time and does not get overwritten when the updated file is used.

Workaround:
Clear PPDCache folder
 
Owner: justincarlson@chromium.org
Status: Assigned (was: Untriaged)
Project Member

Comment 2 by bugdroid1@chromium.org, Jan 24 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d9a046148a7e0686cd042ad8932d95ed34b70a7e

commit d9a046148a7e0686cd042ad8932d95ed34b70a7e
Author: Justin Carlson <justincarlson@chromium.org>
Date: Wed Jan 24 17:56:06 2018

PpdProvider:  change how the cache gets updated.

Previously, if we found a cached ppd, we would always use that.  THis
means we would never pick up a newer version, if one existed.  It also
meant that we had a really annoying flow when a user supplied a broken
ppd and wanted to update that ppd with something fixed from the same
file location -- we wouldn't pick up the changes in the file because
we had already cached the bad version, and we happily used the bad
cached version instead of looking at the user's new file.

So this change updates PpdProvider to sometimes continue the
resolution flow even if it hits in the cache.  It will continue the
flow if the entry in the cache is sufficiently old that we want to
look for an update (the staleness window is controlled by
PpdProvider::Options::cache_staleness_age, and defaults to 2 weeks).
It will also continue the resolution flow if the source of the ppd is
a user-supplied file, regardless of the staleness of the cache entry.

If, after we had a cache hit and continue resolution, resolution fails, then we still supply the cached version.

This buys us a couple of nice behaviours:

For user-supplied ppds, we'll pick up updates to the ppd if the file
changes.  However, if the user removes the user-supplied ppd from
their space, we'll continue to use the last verison we saw, from the
cache.

For network-supplied ppds, we'll automatically check for and get
updates to ppds once in a while, instead of using a cached version
indefinitely.

Also added unit tests around these particular useful semantics.

Bug: 624920,  750386 
Change-Id: I6682d6afd3ad4e321e56809661b051a8737cc98d
Reviewed-on: https://chromium-review.googlesource.com/877319
Commit-Queue: Justin Carlson <justincarlson@chromium.org>
Reviewed-by: Sean Kau <skau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531601}
[modify] https://crrev.com/d9a046148a7e0686cd042ad8932d95ed34b70a7e/chromeos/printing/ppd_cache.cc
[modify] https://crrev.com/d9a046148a7e0686cd042ad8932d95ed34b70a7e/chromeos/printing/ppd_cache.h
[modify] https://crrev.com/d9a046148a7e0686cd042ad8932d95ed34b70a7e/chromeos/printing/ppd_cache_unittest.cc
[modify] https://crrev.com/d9a046148a7e0686cd042ad8932d95ed34b70a7e/chromeos/printing/ppd_provider.cc
[modify] https://crrev.com/d9a046148a7e0686cd042ad8932d95ed34b70a7e/chromeos/printing/ppd_provider.h
[modify] https://crrev.com/d9a046148a7e0686cd042ad8932d95ed34b70a7e/chromeos/printing/ppd_provider_unittest.cc

Status: Fixed (was: Assigned)

Sign in to add a comment