diff tab failure for release 11.10RC2

added frontend regression regression:11.10 labels

mentioned in issue gitlab-org/release/tasks#731 (closed)

@nolith @mayra-cabrera Could you please help out @jarv and @skarbek to track this problem down?

Same link is working well on firefox:

https://staging.gitlab.com/gitlab-org/gitlab-ce/merge_requests/14775/diffs

@mayra-cabrera Great catch, I use Firefox so didn't notice the problem. Confirmed now that it does not work in Chrome.

It's also not working on Safari.

added priority1 severity1 labels

marking this ~S1 ~P1 for now since we want to hold off on releasing until this is better understood

headers dump:

$ curl -i https://gl-staging-canary.freetls.fastly.net/assets/webpack/tree_worker.90f662e9.worker.js
HTTP/2 200
server: nginx
content-type: application/javascript
cache-control: public
expires: Wed, 08 Apr 2020 16:11:51 GMT
last-modified: Thu, 04 Apr 2019 23:44:04 GMT
x-request-id: wZziDj4uY1a
strict-transport-security: max-age=31536000
referrer-policy: strict-origin-when-cross-origin
content-security-policy: object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://gl-staging.freetls.fastly.net https://gl-staging-canary.freetls.fastly.net https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.recaptcha.net/ https://apis.google.com; style-src 'self' 'unsafe-inline' https://gl-staging.freetls.fastly.net https://gl-staging-canary.freetls.fastly.net ; img-src * data: blob:; frame-src 'self' https://www.google.com/recaptcha/ https://www.recaptcha.net/ https://content.googleapis.com https://content-cloudresourcemanager.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://*.codesandbox.io; frame-ancestors 'self'; connect-src 'self' https://gl-staging.freetls.fastly.net https://gl-staging-canary.freetls.fastly.net wss://gitlab.com wss://staging.gitlab.com wss://gstg.gitlab.com https://sentry.gitlab.net https://customers.gitlab.com https://snowplow.trx.gitlab.net
accept-ranges: bytes
date: Mon, 08 Apr 2019 16:20:57 GMT
via: 1.1 varnish
age: 547
x-served-by: cache-mxp19822-MXP
x-cache: HIT
x-cache-hits: 1
x-timer: S1554740458.909515,VS0,VE12
vary: Accept-Encoding,Origin
x-robots-tag: noindex
content-length: 22245

content-security-policy:

object-src 'none';
script-src 'self' 'unsafe-inline' 'unsafe-eval' https://gl-staging.freetls.fastly.net https://gl-staging-canary.freetls.fastly.net https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.recaptcha.net/ https://apis.google.com;
style-src 'self' 'unsafe-inline' https://gl-staging.freetls.fastly.net https://gl-staging-canary.freetls.fastly.net ;
img-src * data: blob:;
frame-src 'self' https://www.google.com/recaptcha/ https://www.recaptcha.net/ https://content.googleapis.com https://content-cloudresourcemanager.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://*.codesandbox.io;
frame-ancestors 'self';
connect-src 'self' https://gl-staging.freetls.fastly.net https://gl-staging-canary.freetls.fastly.net wss://gitlab.com wss://staging.gitlab.com wss://gstg.gitlab.com https://sentry.gitlab.net https://customers.gitlab.com https://snowplow.trx.gitlab.net

In https://gl-staging-canary.freetls.fastly.net/assets/webpack/pages.projects.merge_requests.show.d9609a34.chunk.js, this line of code is causing the issue:

function(e,t,n){e.exports=function(){return new Worker(n.p+"tree_worker.90f662e9.worker.js")}}

Chrome does seem like it's blocking Worker, either because it thinks it's a local file or the CORS policy doesn't allow it: https://stackoverflow.com/a/23206866

mentioned in issue gitlab-org/release/tasks#730 (closed)

It seems tree_worker was introduced on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24392/, should we revert? cc @iamphill

I wonder if we can fix this by adding the require-sri-for CORS header:

Actually, maybe it's the worker-src field is what we need: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src

Ironically, I think GPRD has worker-src defined, but GSTG does not.

interesting, I am not sure why this was configured on gprd but not gstg, it might have been this way for awhile. I will update it

Added in https://ops.gitlab.net/gitlab-cookbooks/chef-repo/merge_requests/974

For reference via https://cspvalidator.org, GPRD:

GSTG:

It looks like worker-src is the only thing missing.

It should be noted that the work @jarv performed above has been reverted as we started to see 500's spawning from haproxy. Further tests later in the day did not provide us with any forward progress either.

I'm wondering if this isn't a CSP problem at all because the error doesn't say denied by the document's Content Security Policy. Chrome may not allow a file from gl-staging.canary.freetls.fastly.net to access a Worker defined on staging.gitlab.com.

From https://benohead.com/cross-domain-cross-browser-web-workers/:

You are limited by the same origin policy i.e. the worker script must be served from the same domain (including the protocol) as the script that is creating the worker

I think this is the problem, so we either have to correct the URL generated by that JavaScript or revert.

@mikegreiling Is this due to worker-loader and something we can configure easily?

https://webpack.js.org/loaders/worker-loader/#cross-origin-policy has some possible options here? It looks like we set publicPath at the moment, but perhaps inlining is an option here?

Heh, I see that we enabled inlining for dev, but not for production! https://gitlab.com/gitlab-org/gitlab-ce/commit/241f0110ca0065262c3548051a06818a14da15b0

publicPath also isn't set there.

I propose that we do a test build with a CDN somehow with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27152.

@mikegreiling mentioned that inlining doesn't work with all browsers (https://github.com/webpack-contrib/worker-loader/blob/master/src/workers/InlineWorker.js), so we may want to just disable the CDN for Worker scripts. @iamphill Does the following do the trick (see https://github.com/webpack-contrib/worker-loader/blob/master/src/workers/index.js)?

diff --git a/config/webpack.config.js b/config/webpack.config.js
index 19b48845305..323fd291e01 100644
--- a/config/webpack.config.js
+++ b/config/webpack.config.js
@@ -173,6 +173,7 @@ module.exports = {
             options: {
               name: '[name].[hash:8].worker.js',
               inline: IS_DEV_SERVER,
+              publicPath: '/assets/webpack/',
             },
           },
           'babel-loader',

@stanhu I don't believe that will work. We will need to set the publicPath at runtime, not compile time.

Right, I just realized that probably doesn't work. :( What are our options here?

Also https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24392/diffs shipped in 11.8. What's different now?

possibly related: !26066 (merged)

Ok, I get it now. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26015 was added in 11.10 to fix problems with the Web IDE not working with a relative URL path (https://gitlab.com/gitlab-org/gitlab-ce/issues/50451). However, the change causes the Worker scripts to use the CDN when previously it did not.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26066 was originally designed to revert that change, but we realized we can fix both issues by setting:

_webpack_public_path__ for Webpack
(non-standard) window.__webpack_public_path__ for Monaco

mentioned in commit 8a9c18ca

mentioned in merge request !27152 (closed)

added typebug label

mentioned in merge request !26066 (merged)

mentioned in issue #60257 (moved)

assigned to @mikegreiling

changed milestone to %11.10

closed via merge request !26066 (merged)

mentioned in commit 5cc1d2f1

mentioned in commit 9f38d3db

diff tab failure for release 11.10RC2

Designs

Child items ...

Activity