Service worker caching broken (Chromium 67.0.3372.0)
Reported by
drmrbre...@gmail.com,
Mar 20 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Steps to reproduce the problem: The latest puppeteer v1.2.0 uses Chromium 67.0.3372.0 (r543305): https://github.com/GoogleChrome/puppeteer/releases/tag/v1.2.0 I find that this version of Chromium breaks my service worker caching. When using the same cache folder between page loads (by passing the same `userDataDir`), loading the following node server page the first time should say "fetched from network" and then on reloading twice (when stuff is fully cached in service worker), it should change to "retrieved from service worker cache". You can see this behaviour in a normal chrome browser by loading the URL used below (https://cloud3squared.com/files/sw-chromium-bug/index.html) and then hitting F5 a few times. When screenshotting this page with puppeteer/chrome, it has been working exactly as explained above... but now when I try the chromium version that is shipping with puppeteer 1.2.0, it is no longer working... however many reloads still shows "fetched from network"... and the cache quota info also displayed on the page shows as zero. node.js code: #!/bin/env node const express = require('express'); const puppeteer = require('puppeteer'); const path = require('path'); const app = express(); const test = async function (req, res, next) { // this demo works works when using the following version ... // const browserVersion = '539001'; // 66.0.3355.0 // but NOT with the version shipped with puppeteer 1.2.0 ... const browserVersion = '543305'; // 67.0.3372.0 const browserFetcher = puppeteer.createBrowserFetcher(); const revisionInfo = await browserFetcher.download(browserVersion); const userDataDir = path.join(__dirname, '.puppeteer-user-data-dir'); const launchOptions = { userDataDir: userDataDir, executablePath: revisionInfo.executablePath }; const browser = await puppeteer.launch(launchOptions); const page = await browser.newPage(); await page.goto('https://cloud3squared.com/files/sw-chromium-bug/index.html', { waitUntil: 'networkidle0' }); const screenshotBuffer = await page.screenshot(); await browser.close(); res.header('Content-Type', 'image/png'); res.send(screenshotBuffer); }; app.get('/test', test); app.listen(process.env.PORT || 8080, process.env.IP, function () { console.log('node server started at', new Date()); }); What is the expected behavior? See above What went wrong? See above Did this work before? N/A Does this work in other browsers? N/A Chrome version: 67.0.3372.0 (543305) Channel: n/a OS Version: Flash Version: I also reported this over at puppeteer but got no response: https://github.com/GoogleChrome/puppeteer/issues/2212
,
Mar 20 2018
> You can see this behaviour in a normal chrome browser by loading the URL used below (https://cloud3squared.com/files/sw-chromium-bug/index.html) and then hitting F5 a few times. Just to be sure, are you saying that the bug can be seen in a normal Chrome browser by loading that page? (Or does "this behaviour" mean the desired behavior?) I see the desired behavior in today's Canary 67.0.3376.1. After reloading, "retrieved from service worker cache" is displayed.
,
Mar 20 2018
Sorry, in that statement I meant "this behaviour" to be the "desired behaviour"... i.e. loading that page in a normal (non bleeding edge e.g. 65.0.3325.162) chrome browser results in the expected behaviour. But loading that page via the latest version of puppeteer (with bundled chrome 67.0.3372.0 r543305) results in the incorrect behaviour. I haven't tried 67.0.3376.1... looking at https://omahaproxy.appspot.com/ it seemed to me that the latest available for linux right now is 67.0.3371.0 (543278)... I did try loading that in the above code but browserFetcher couldn't find it. So the latest I tried is the one bundled with puppeteer 1.2.0, which is 67.0.3372.0 (543305)... which very confusingly is actually *ahead* of what is showing at omahaproxy.
,
Mar 20 2018
OK just tried 67.0.3376.1 (r544068) via puppeteer (using the above node.js code but using browserVersion = '544068' instead)... and it also fails... see attached output after several reloads. So if that version is working outside the puppeteer environment (I haven't tried) then maybe it is puppeteer specific?
,
Mar 20 2018
On the other hand, the attached is what I see (after a couple of reloads) when using browserVersion = '539001' (i.e. 66.0.3355.0 r539001)
,
Mar 20 2018
I see. In c#2 I meant that I tested in Chrome, not Puppeteer. cc DevTools who seem to own Puppetteer, though if I understand your node.js script correctly it does seem to indicate the regression happened in Chrome. I don't really know how to debug this. I would suggest bisecting Chrome versions between 539001 and 543305 with your script.
,
Mar 22 2018
The issue seems to be related to Puppeteer tool which is a Node library which provides a high-level API to control headless Chrome or Chromium over the DevTools Protocol. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team. Thanks...!!
,
Mar 23 2018
,
Dec 19
According to downstream bug, there's some timing that has changed regarding service worker registrations. If Puppeteer script wait for right events, than everything works fine. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by pauljensen@chromium.org
, Mar 20 2018