core: INSECURE_DOCUMENT_REQUEST errors still return lhr #6608

connorjclark · 2018-11-19T23:42:55Z

connorjclark · 2018-11-19T23:47:02Z

Bad bot. why would you close a PR

patrickhulce · 2018-11-20T01:34:25Z

Could we get a bit of explanation for what was happening before and why we want this instead? :)

patrickhulce · 2018-11-20T01:38:43Z

lighthouse-core/gather/gather-runner.js

-    await GatherRunner.loadPage(driver, passContext);
-    log.timeEnd(status);
+    try {
+      await GatherRunner.loadPage(driver, passContext);


we're injecting a lot of new if/try/catch blocks into some already beefy methods, do you think there's a way we might be able to push some of these complications down a level so the busier method is still easy to parse?

yes, if we can refactor Runner.run to easily return a (errored) LHR in its catch. Then changes to gather-runner wouldn't be necessary.

We're dropping the LHR requirement for now, so we can also drop these changes (there won't be a timing object to add this to if an error was thrown)

connorjclark · 2018-11-20T01:43:34Z

When there is a security issue, Page.navigate timesout, and the entire LH run is aborted fatally without returning a LHR. If ignored, more commands hang forever (Network.emulateNetworkConditions) - so the gather runner aborts as soon as it detects a security issue.

connorjclark · 2018-11-20T01:45:45Z

It would be much nicer if we could just throw the security error when discovered (like the PR has it in driver.goToURL), and don't attempt to handle it at all in the gather runner, letting it go up to the catch in Runner.run, and just returning a bare LHR with the runtimeError set. But that seems like a bigger change. All the complication in this code is just to set up the gatherer artifacts in a way that still produces a LHR...

brendankenny · 2018-11-20T19:24:45Z

But that seems like a bigger change. All the complication in this code is just to set up the gatherer artifacts in a way that still produces a LHR...

We should definitely do it the right way, even if it's more work, otherwise we're just going to keep paying for it until we do. It's already enough work to mentally reconstruct control flow through GatherRunner and page load in Driver, we don't want to add more branches if we don't have to :)

However, I think this gets back to #6336, which I failed to substatially bring up in the bug (#6595 (comment) :).

It's still not clear to me that we want an LHR with just the single top-level error for the CLI/Extension/DevTools clients (they have varying extents of their own UI for showing fatal errors like this). I feel like we need to settle the question of how to treat runtime errors in the different clients before we start any error-handling refactors.

connorjclark · 2018-12-18T18:05:35Z

OK, I removed all that complexity. Test w/ node lighthouse-cli https://expired.badssl.com/ --view to see that the run bails immediately on a security issue, instead of hanging.

The original issue requested returning an LHR, but I believe we don't care about that anymore, since LR now correctly forms a LHR when an error is thrown. @paulirish is this correct?

brendankenny · 2018-12-18T18:25:05Z

The original issue requested returning an LHR, but I believe we don't care about that anymore, since LR now correctly forms a LHR when an error is thrown.

a million 👍s from me :)

exterkamp · 2018-12-18T20:37:17Z

lighthouse-core/lib/lh-error.js

@@ -22,7 +22,7 @@ const UIStrings = {
  /** Error message explaining that Lighthouse could not load the requested URL and the steps that might be taken to fix the unreliability. */
  pageLoadFailedWithDetails: 'Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: {errorDetails})',
  /** Error message explaining that the credentials included in the Lighthouse run were invalid, so the URL cannot be accessed. */
-  pageLoadFailedInsecure: 'The URL you have provided does not have valid security credentials. ({securityMessages})',
+  pageLoadFailedInsecure: 'The URL you have provided does not have valid security credentials. {securityMessages}',


Any reason for removing these? I feel like a list that might make no sense as a sentence like this belongs in parens. e.g. The URL...credentials. (Reason 1 Reason 2)

A realistic error message reads like this:

The URL you have provided does not have valid security credentials. This site is missing a valid, trusted certificate (net::ERR_CERT_DATE_INVALID).

Which is a valid sentence. So...ignore this maybe.

correct-o, the sentences should make sense as - is.

at least, in english ..

I think we need to add something about securityMessages to the description for the translators. "securityMessages will be replaced with one or more strings from the browser explaining what was insecure about the page load." or whatever

exterkamp · 2018-12-18T20:47:31Z

lighthouse-core/lib/file-namer.js

@@ -16,11 +16,11 @@
 * Generate a filenamePrefix of hostname_YYYY-MM-DD_HH-MM-SS
 * Date/time uses the local timezone, however Node has unreliable ICU
 * support, so we must construct a YYYY-MM-DD date format manually. :/
- * @param {{finalUrl: string, fetchTime: string}} lhr
+ * @param {{requestedUrl: string, finalUrl: string, fetchTime: string}} lhr


What is this requestedUrl business about? Does it relate to INSECURE DOC requests?

if the doc fails to load, the "finalUrl" is never set. so fall back to requestUrl

What is this requestedUrl business about?

I believe left over from the old version of the PR, should be able to remove from here now (and from github-api.js and report-ui-features.js)

Oof you're right, forgot to check if that was still necessary.

brendankenny

big move request :)

brendankenny · 2018-12-18T21:42:25Z

lighthouse-core/gather/driver.js

+    }
+  }
+
+  waitForSecurityIssuesCheck() {


can we just combine the two of these? Seems unnecessary to split (waitForSecurityIssuesCheck doesn't really do anything in isolation and they aren't called separately)

we talked earlier about the order of the listener vs calling enable().

......maybe the order right now is OK. if you listened before calling security.enable then perhaps you would get a statechanged event for the about:blank state.

I'm not totally sure about this.

but typically we do like setting up the event listener before enable is called, because enable usually flushes all events before it results.

brendankenny · 2018-12-18T21:48:12Z

lighthouse-core/gather/driver.js

+      await this.waitForSecurityIssuesCheck();
+    } finally {
+      this.sendCommand('Security.disable');
+    }


To do this right, I think @paulirish is right and this should move into waitForFullyLoaded. We shouldn't be mucking around looking at network traffic before our traffic monitor is allowed to start monitoring :)

Take a look at this._waitForLoadEvent or this._waitForNetworkIdle for the promise/cancel cancellable promise model used, and _waitForFullyLoaded itself for where to put it in parallel with the timeout. It should be a pretty simple translation from waitForSecurityIssuesCheck already in this PR.

(and forgive the state of the code in those methods...they're super old and have pretty much only grown through accretion, not really refactored, so they're a bit creaky and brittle :)

what about the _waitForFrameNavigated case?

what about the _waitForFrameNavigated case?

that's only used for loading about:blank, so we're ok there. We should probably make that clearer, though really if you're saying waitForNavigated: true, you're basically forgoing all our checks already.

brendankenny · 2018-12-18T21:49:16Z

lighthouse-core/gather/gather-runner.js

-    await GatherRunner.loadPage(driver, passContext);
-    log.timeEnd(status);
+    try {
+      await GatherRunner.loadPage(driver, passContext);


We're dropping the LHR requirement for now, so we can also drop these changes (there won't be a timing object to add this to if an error was thrown)

connorjclark · 2018-12-19T23:25:32Z

lighthouse-core/gather/driver.js

+
+      // wait for Security.enable to resolve, so we skip whatever state change
+      // events are in the pipeline
+      await this.sendCommand('Security.enable');


I can't really explain it, but this only works when awaiting the Security.enable ...

do we have some tests/a test that can capture the cases that fail without this await but succeed with?

this also seems a bit like it has the potential to race :/

The test would basically be 1) go to https://expired.badssl.com/ (or load page with bad cert) 2) assert LH does not hang / exercise the full page load time out (so, within 5s??)

would that be a good candidate for a smoke test?

OK, it looks like it starts with the "neutral" security state (about: has no meaningful value for security) and then either goes to "secure" or "insecure", depending on the target page. So I can tweak the logic to listen for state changes until "not neutral" comes up

would that be a good candidate for a smoke test?

sounds great to me! ~~who maintains badssl? do we expect it to be roughly up most of the time?~~ oh we do, awesome yeah let's do it :D https://github.com/chromium/badssl.com

Just https://localhost:10200 could also work

If in offline mode, the security state is always "neutral" ...

This is me running the pwa smoke test. First two security states are the online pass (neutral -> secure), last three(?) are the offline pass (neutral -> neutral... but with explanations)

But in each case, the first state we care about is the first one with non-empty explanations. So maybe use that?

Which makes sense... if there's no explanation for a security state, why value it?

For some reason, some offline urls gives three empty, neutral states in the offline pass. Perhaps better to just disable this check for the offline pass.

patrickhulce · 2018-12-20T00:09:12Z

lighthouse-core/gather/driver.js

+
+      // wait for Security.enable to resolve, so we skip whatever state change
+      // events are in the pipeline
+      await this.sendCommand('Security.enable');


do we have some tests/a test that can capture the cases that fail without this await but succeed with?

patrickhulce · 2018-12-20T00:09:49Z

lighthouse-core/gather/driver.js

+
+      // wait for Security.enable to resolve, so we skip whatever state change
+      // events are in the pipeline
+      await this.sendCommand('Security.enable');


this also seems a bit like it has the potential to race :/

patrickhulce · 2018-12-20T00:10:28Z

lighthouse-core/gather/driver.js

+       * @param {LH.Crdp.Security.SecurityStateChangedEvent} event
+       */
+      const securityStateChangedListener = ({securityState, explanations}) => {
+        this.sendCommand('Security.disable');


do we need this in a promise chain like @exterkamp's cleanup?

Do you mean adding an await here?

or an empty .catch if we don't care?

patrickhulce · 2018-12-20T00:10:43Z

lighthouse-core/gather/driver.js

+
+      cancel = () => {
+        this.off('Security.securityStateChanged', securityStateChangedListener);
+        this.sendCommand('Security.disable');


same here re: floating promise

patrickhulce · 2018-12-20T00:27:08Z

lighthouse-core/gather/driver.js

@@ -752,6 +795,7 @@ class Driver {
    // Wait for both load promises. Resolves on cleanup function the clears load
    // timeout timer.
    const loadPromise = Promise.all([
+      waitForSecurityCheck.promise,


this makes me a tad more nervous I feel like we need some beefier commenting on why this is OK, intuitively I wouldn't expect a securityStateChanged to be guaranteed to fire early on every single page load, i.e. why would it fire if I go from http to http or https to https or about: to about:, etc

putting it directly in the chain of waiting for load just makes it a bit high stakes

I think it'd only work if the Security domain is disabled before _waitForFullyLoaded runs. If a gatherer were to enable Security and forget to disable it, this may break?

Also, isn't this method always called from "about:" -> "target url"?

Also, isn't this method always called from "about:" -> "target url"?

That's kinda what I'm talking about, just explaining why this is always going to be OK :)

Ah, OK I misunderstood. How's the comment I added?

nice! maybe we can add a sentence about how it resolves too not just reject?

I'm thinking something like

// Listener that resolves or rejects on the first security state change. // If the first change is secure, we resolve. // If the first change is insecure, we reject. // We can expect the security state to always change because this function // is only used to move about:blank (neutral) -> the target url (something not neutral).

Now that I'm thinking about it maybe it belongs in the _waitForSecurityCheck jsdoc :)

paulirish · 2019-01-08T20:56:24Z

lighthouse-cli/test/smokehouse/smokehouse.js

@@ -16,6 +16,7 @@ const log = require('lighthouse-logger');

 const PROTOCOL_TIMEOUT_EXIT_CODE = 67;
 const PAGE_HUNG_EXIT_CODE = 68;
+const INSECRE_DOCUMENT_REQUEST_EXIT_CODE = 69;


paulirish · 2019-01-08T21:12:47Z

lighthouse-core/gather/driver.js

@@ -32,6 +32,8 @@ const DEFAULT_CPU_QUIET_THRESHOLD = 0;
 // Controls how long to wait for a response after sending a DevTools protocol command.
 const DEFAULT_PROTOCOL_TIMEOUT = 30000;

+const SECURE_SCHEMES = ['data', 'https', 'wss', 'blob', 'chrome', 'chrome-extension', 'about'];


remains to be seen if we need this here, but if we do, i'd much rather this array live in a common place than be duplicated here and in the is-on-https audit.
url-shim.js has worked well in the past. move there and import to here and the audit?

update: yup, this stuff is unnecessary now, but FYI on the feedback.

paulirish · 2019-01-08T21:39:57Z

lighthouse-core/gather/driver.js

@@ -741,6 +792,14 @@ class Driver {
    /** @type {NodeJS.Timer|undefined} */
    let maxTimeoutHandle;

+    // Noop if offline or not https
+    // https: => https
+    const protocol = new URL(this._monitoredUrl || '').protocol.replace(/:$/, '');


Good call, Brendan.

Example URL that redirects to insecure (but isn't caught currently): http://i.paul.irish
(as soon as DNS propagates, http://expiredredirect.paul.irish will do the same)

patrickhulce · 2019-01-08T23:54:57Z

lighthouse-cli/run.js

@@ -23,6 +23,7 @@ const opn = require('opn');
 const _RUNTIME_ERROR_CODE = 1;
 const _PROTOCOL_TIMEOUT_EXIT_CODE = 67;
 const _PAGE_HUNG_EXIT_CODE = 68;
+const _INSECRE_DOCUMENT_REQUEST_EXIT_CODE = 69;


still INSECRE ;)

patrickhulce · 2019-01-09T05:08:54Z

lighthouse-core/gather/driver.js

@@ -832,9 +857,11 @@ class Driver {

    // Wait for load or timeout and run the cleanup function the winner returns.


edit this comment to note that securityCheckPromise will only ever reject?

OR crazy idea, the promise resolves with a cleanupFn that throws an error :D then the three cases are a little more parallel

to your second comment, so securityCheckPromise would be changed to resolve instead of reject?

to your second comment, so securityCheckPromise would be changed to resolve instead of reject?

right it would go hand-in-hand with #6608 (comment) to enable to refactor

patrickhulce · 2019-01-09T05:13:36Z

lighthouse-core/gather/driver.js

+
+    // Promise that only rejects when an insecure security state is encountered
+    let securityCheckCleanup = () => {};
+    const securityCheckPromise = new Promise((_, reject) => {


there's a lot to unpack in this function that needs longstanding cleanup I'll take a whack at as a followup to #6944, for now WDYT about sticking this in a _waitForSecurityError or something following the {promise, cancel} paradigm we have currently?

The cancelAll and clearing the maxTimeoutHandle complicates that a lot. It's not clear to me how to extract into a function without using multiple parameter callbacks (or is that the cleanup you had in mind?)

yeah this goes hand-in-hand with the resolve idea. I'm not sure we could easily pull it out with it still rejecting immediately

OK, I think I see how that'd work. I'll give it a shot

connorjclark · 2019-01-09T18:44:55Z

lighthouse-core/gather/driver.js

-        waitForLoadEvent.cancel();
-        waitForNetworkIdle.cancel();
-        waitForCPUIdle.cancel();
+        waitForSecurityCheck.cancel();


I think it'd be easier to reason about all this canceling if each cancelable promise stores state about if it's been canceled yet and avoids doing it more than once. Then we could judiciously use cancelAll in one place, after the Promise race.

Yeah this is ripe for cleanup, but this new parallel style will make it so much easier now, thank you!!

FWIW, I don't think anything would be harmed today if you threw this into cancelAll right?

would also have to remove the self-cancel that _waitForSecurityCheck does, otherwise it would cancel itself twice.

I'll try the cancel state thing first

hang on before you do that I was saying I don't think it would matter if we called cancel twice, we're just extra disabling the security domain and removing a listener that might've been removed already.

OK, LMK if that is better or worse

patrickhulce

looks pretty good to me!

patrickhulce · 2019-01-09T23:33:52Z

lighthouse-core/gather/driver.js

@@ -698,7 +697,6 @@ class Driver {
    const promise = new Promise((resolve, reject) => {
      checkForQuiet(this, resolve).catch(reject);
      cancel = () => {
-        cancelled = true;


this feels like a bug, we want to just add if (cancelled) return right?

oops, didn't meant to delete that.

can skip the guard here since reject/clearTimeout should have no effect after the first call.

of course, leaving out the guard looks like a mistake, so perhaps I should just add it anyways?

can skip the guard here since reject/clearTimeout should have no effect after the first call.

of course, leaving out the guard looks like a mistake, so perhaps I should just add it anyways?

I mean, it's also unnecessary everywhere else it's be added, isn't it? All removing listeners and clearing timeouts, which have no problem being run multiple times.

I'm OK with having them since that's how we would write a cancellable promise utility instead of doing each of these separately (in which case all of the methods should have it), but I'm also OK with dropping them since they aren't necessary (except for the Security.disable command in _waitForSecurityCheck)

patrickhulce · 2019-01-09T23:36:08Z

lighthouse-core/gather/driver.js

@@ -793,6 +840,13 @@ class Driver {
    // CPU listener. Resolves when the CPU has been idle for cpuQuietThresholdMs after network idle.
    let waitForCPUIdle = this._waitForNothing();

+    const waitForSecurityCheck = this._waitForSecurityCheck();
+    const securityCheckPromise = waitForSecurityCheck.promise.then((err) => {


super nit: but I might have the promise resolve with the explanations and this fn create the error.

that feels a little more mainstream to resolve with data and then the type of the error is clear from within this fn

patrickhulce · 2019-01-09T23:38:54Z

lighthouse-core/test/gather/driver-test.js

@@ -22,7 +22,10 @@ const redirectDevtoolsLog = require('../fixtures/wikipedia-redirect.devtoolslog.
 const MAX_WAIT_FOR_PROTOCOL = 20;

 function createOnceStub(events) {
-  return (eventName, cb) => {
+  return async (eventName, cb) => {
+    // wait a tick b/c real events never fire immediately


patrickhulce

LGTM!

brendankenny

looking good. A few style things but nothing too big

brendankenny · 2019-01-10T20:04:14Z

lighthouse-core/gather/driver.js

@@ -666,7 +665,7 @@ class Driver {

    /** @type {NodeJS.Timer|undefined} */
    let lastTimeout;
-    let cancelled = false;
+    let canceled = false;


boooo to one L :P

I prefer Mr. Webster's simplified spellings, but I could care more.

brendankenny · 2019-01-10T20:09:26Z

lighthouse-core/gather/driver.js

@@ -698,7 +697,6 @@ class Driver {
    const promise = new Promise((resolve, reject) => {
      checkForQuiet(this, resolve).catch(reject);
      cancel = () => {
-        cancelled = true;


can skip the guard here since reject/clearTimeout should have no effect after the first call.

of course, leaving out the guard looks like a mistake, so perhaps I should just add it anyways?

I mean, it's also unnecessary everywhere else it's be added, isn't it? All removing listeners and clearing timeouts, which have no problem being run multiple times.

I'm OK with having them since that's how we would write a cancellable promise utility instead of doing each of these separately (in which case all of the methods should have it), but I'm also OK with dropping them since they aren't necessary (except for the Security.disable command in _waitForSecurityCheck)

brendankenny · 2019-01-10T20:10:27Z

lighthouse-core/gather/driver.js

        if (lastTimeout) clearTimeout(lastTimeout);
-        reject(new Error('Wait for CPU idle cancelled'));
+        reject(new Error('Wait for CPU idle canceled'));


interesting that we reject here but not in the others

brendankenny · 2019-01-10T20:12:57Z

lighthouse-core/gather/driver.js

+        if (canceled) return;
+        canceled = true;
+        this.off('Security.securityStateChanged', securityStateChangedListener);
+        this.sendCommand('Security.disable').catch(() => {});


maybe add a TODO here for whatever @patrickhulce is planning with the refactor? cancel() should really be a promise itself to handle things like this

brendankenny · 2019-01-10T20:20:06Z

lighthouse-core/gather/driver.js

+   * @return {{promise: Promise<LH.Crdp.Security.SecurityStateExplanation[]>, cancel: function(): void}}
+   * @private
+   */
+  _waitForSecurityCheck() {


rename since it resolves only in the case of insecurity (and the check isn't singular, it just goes until it isn't needed)? _waitForInsecureState? _monitorForInsecureState? Something else?

brendankenny · 2019-01-10T20:29:54Z

lighthouse-core/gather/driver.js

-        waitForLoadEvent.cancel();
-        waitForNetworkIdle.cancel();
-        waitForCPUIdle.cancel();
-
        if (await this.isPageHung()) {


FWIW for future refactoring, @paulirish mentioned he doesn't think this check is necessary anymore (errors are successfully being detected elsewhere, I guess)

brendankenny · 2019-01-10T20:36:28Z

lighthouse-core/gather/driver.js

+        });
+        throw err;
+      };
+    });


ha, I think I disagree with @patrickhulce. The internals of SecurityStateExplanation seem like a distraction from the actual purpose of _waitForFullyLoaded, since either way we're using waitForSecurityCheck to alert us of an error, the question is if we should do more work in there or out here.

If that's not convincing, maybe we could split the difference? Filter and map within _waitForSecurityCheck and then it only needs to be

const securityCheckPromise = waitForSecurityCheck.promise.then(securityMessages => { return function() { throw new new LHError(LHError.errors.INSECURE_DOCUMENT_REQUEST, {securityMessages}); } });

(using the cleanupFn to reject the promise is a little weird but w/e :P)

brendankenny · 2019-01-10T20:37:46Z

lighthouse-core/gather/driver.js

@@ -830,11 +879,20 @@ class Driver {
      };
    });

-    // Wait for load or timeout and run the cleanup function the winner returns.
+    // Wait for security issue, load or timeout and run the cleanup function the winner returns.
    const cleanupFn = await Promise.race([


having this cleanupFn setup now is weird if they all can (and should) be cancelled regardless, but that can wait for the refactor too

brendankenny · 2019-01-10T20:39:44Z

lighthouse-core/lib/lh-error.js

@@ -22,7 +22,7 @@ const UIStrings = {
  /** Error message explaining that Lighthouse could not load the requested URL and the steps that might be taken to fix the unreliability. */
  pageLoadFailedWithDetails: 'Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: {errorDetails})',
  /** Error message explaining that the credentials included in the Lighthouse run were invalid, so the URL cannot be accessed. */
-  pageLoadFailedInsecure: 'The URL you have provided does not have valid security credentials. ({securityMessages})',
+  pageLoadFailedInsecure: 'The URL you have provided does not have valid security credentials. {securityMessages}',


I think we need to add something about securityMessages to the description for the translators. "securityMessages will be replaced with one or more strings from the browser explaining what was insecure about the page load." or whatever

paulirish

functionally, this works great.

You'll want to add this at the top of popup.js:

  'INSECURE_DOCUMENT_REQUEST': 'The URL you have provided does not have valid' +
      ' security credentials.',

lgtm on everything else.

brendankenny · 2019-01-10T21:07:50Z

lighthouse-core/test/gather/driver-test.js

@@ -22,7 +22,10 @@ const redirectDevtoolsLog = require('../fixtures/wikipedia-redirect.devtoolslog.
 const MAX_WAIT_FOR_PROTOCOL = 20;

 function createOnceStub(events) {
-  return (eventName, cb) => {
+  return async (eventName, cb) => {


this is a weird use of async/await (and depending on driver.once calls you'll end up with an unhandled promise rejection for the throw below).

Can we just

// wait a tick b/c real events never fire immediately setTimeout(_ => cb(events[eventName]), 0); return;

like normal people? :P

I meant drop the async/await in favor of the setTimeout :)

brendankenny · 2019-01-10T22:41:32Z

lighthouse-core/test/gather/driver-test.js

+        explanations: [],
+        securityState: 'secure',
+      };
+      driverStub.on = driverStub.once = createOnceStub({


this poor driverStub was never meant to be used repeatedly :)

Can you also break the cycle and make a new Driver(connection) within each of these tests? We can deal with having a fresh connection later

FWIW I'm also rather fond of keeping all the mocking close to the test like I did over in manifest PR with jest.spyOn. Given the way the past few reviews have gone I'm guessing @brendankenny feels the opposite though so take it with a grain of salt 😂

Given the way the past few reviews have gone I'm guessing @brendankenny feels the opposite

Ha, I'm not entirely sure how to interpret that. I also like maximizing locality so you can see what's actually been done to the mock you have to use. But I am generally against mocks if at all possible, if that's what that means :)

I also like maximizing locality

phew! :)

Ha, I'm not entirely sure how to interpret that.

only a joke no worries, just I feel like I've lead @hoten chasing too many wild geese lately 😆

only a joke no worries

lol I was trying to read too deeply :) :)

brendankenny · 2019-01-11T20:07:59Z

@hoten you'll need to rerun yarn diff:sample-json to pick up the new description

brendankenny

just the one test change and rerun yarn diff:sample-json and I think we may be good to go!

brendankenny · 2019-01-11T20:45:20Z

lighthouse-core/test/gather/driver-test.js

@@ -22,7 +22,10 @@ const redirectDevtoolsLog = require('../fixtures/wikipedia-redirect.devtoolslog.
 const MAX_WAIT_FOR_PROTOCOL = 20;

 function createOnceStub(events) {
-  return (eventName, cb) => {
+  return async (eventName, cb) => {


I meant drop the async/await in favor of the setTimeout :)

brendankenny · 2019-01-11T20:45:55Z

lighthouse-core/test/gather/driver-test.js

+  const connection = new Connection();
+  connection.sendCommand = sendCommandStub;
+  driverStub = new Driver(connection);
+});


too slow

brendankenny · 2019-01-11T23:42:43Z

connorjclark · 2019-01-12T00:14:30Z

INSECURE_DOCUMENT_REQUEST errors still return lhr (#6595)

4c658fb

connorjclark requested review from brendankenny, ebidel, patrickhulce and paulirish as code owners November 19, 2018 23:42

This comment has been minimized.

Sign in to view

devtools-bot added the duplicate label Nov 19, 2018

devtools-bot closed this Nov 19, 2018

connorjclark reopened this Nov 19, 2018

connorjclark removed the duplicate label Nov 19, 2018

fix comment. remove dead code

eb7f5a3

patrickhulce reviewed Nov 20, 2018

View reviewed changes

paulirish added the 4.0 label Dec 18, 2018

Merge branch 'master' into issue-6595-insecure

62787ee

exterkamp requested changes Dec 18, 2018

View reviewed changes

brendankenny requested changes Dec 18, 2018

View reviewed changes

exterkamp mentioned this pull request Dec 19, 2018

Extension Error: INSECURE_DOCUMENT_REQUEST #6809

Closed

connorjclark added 2 commits December 19, 2018 15:22

move security check to wait for page load

3577e0c

remove finally for timing

2c0b251

connorjclark commented Dec 19, 2018

View reviewed changes

set cancel

e22d9ca

patrickhulce reviewed Dec 20, 2018

View reviewed changes

update test name

9e54f1b

paulirish reviewed Jan 8, 2019

View reviewed changes

connorjclark added 4 commits January 8, 2019 15:16

move security check to promise race. only rejects now.

1e1fc8a

fix typo

0a0e8e0

Merge remote-tracking branch 'origin/master' into issue-6595-insecure

b863fbd

Merge remote-tracking branch 'origin/master' into issue-6595-insecure

da6fd9c

patrickhulce reviewed Jan 9, 2019

View reviewed changes

connorjclark added 2 commits January 9, 2019 09:21

fix typo, add comment

3c54326

make security check cancelable promise again

ab0582b

connorjclark commented Jan 9, 2019

View reviewed changes

simplify cancels

f272978

patrickhulce reviewed Jan 9, 2019

View reviewed changes

connorjclark added 2 commits January 9, 2019 16:12

fix cancel bug

e6a659a

move security error creation

271a80a

patrickhulce approved these changes Jan 10, 2019

View reviewed changes

brendankenny reviewed Jan 10, 2019

View reviewed changes

paulirish reviewed Jan 10, 2019

View reviewed changes

brendankenny reviewed Jan 10, 2019

View reviewed changes

cr changes

8bbcbc4

brendankenny reviewed Jan 10, 2019

View reviewed changes

create driver for each test

04b1f64

brendankenny approved these changes Jan 11, 2019

View reviewed changes

cr changes

1da3b01

brendankenny merged commit 017574b into master Jan 11, 2019

brendankenny deleted the issue-6595-insecure branch January 11, 2019 23:47

brendankenny removed the waiting4committer label Jan 11, 2019

connorjclark mentioned this pull request Jan 15, 2019

Extension Error: INSECURE_DOCUMENT_REQUEST #7012

Closed

		@@ -832,9 +857,11 @@ class Driver {

		// Wait for load or timeout and run the cleanup function the winner returns.

core: INSECURE_DOCUMENT_REQUEST errors still return lhr #6608

core: INSECURE_DOCUMENT_REQUEST errors still return lhr #6608

Conversation

connorjclark commented Nov 19, 2018

This comment has been minimized.

connorjclark commented Nov 19, 2018

patrickhulce commented Nov 20, 2018

Choose a reason for hiding this comment

connorjclark Nov 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark commented Nov 20, 2018

connorjclark commented Nov 20, 2018 • edited Loading

brendankenny commented Nov 20, 2018

connorjclark commented Dec 18, 2018

brendankenny commented Dec 18, 2018

Choose a reason for hiding this comment

exterkamp Dec 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendankenny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark Dec 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark Dec 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark Dec 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulirish Jan 8, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

patrickhulce left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark Nov 20, 2018 •

edited

Loading

connorjclark commented Nov 20, 2018 •

edited

Loading

exterkamp Dec 18, 2018 •

edited

Loading

connorjclark Dec 20, 2018 •

edited

Loading

connorjclark Dec 20, 2018 •

edited

Loading

connorjclark Dec 20, 2018 •

edited

Loading

paulirish Jan 8, 2019 •

edited

Loading