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

Issue 823681 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Last visit 28 days ago
Closed: Dec 19
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Service worker caching broken (Chromium 67.0.3372.0)

Reported by drmrbre...@gmail.com, Mar 20 2018

Issue description

UserAgent: 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
 
Components: Blink>ServiceWorker

Comment 2 by falken@chromium.org, Mar 20 2018

Components: -Blink>Storage Blink>Storage>CacheStorage
> 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.
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.
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?
Capture.JPG
24.9 KB View Download
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)
Capture.JPG
27.9 KB View Download

Comment 6 Deleted

Comment 7 by falken@chromium.org, Mar 20 2018

Cc: lushnikov@chromium.org
Components: Platform>DevTools
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. 
Labels: Triaged-ET TE-NeedsTriageHelp Needs-Triage-M67
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...!!
Owner: lushnikov@chromium.org
Status: Assigned (was: Unconfirmed)
Status: WontFix (was: Assigned)
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