blank page on certain browser plugins injecting stylesheets

[floriangantner]

Describe the bug
Loading DSpace with certain plugins leads to problems and the site will not load correctly resulting in some white page after the initial load.

Screenshot of some white demo page - not really valuable for debugging, i must admit :)

As far as we know some dark mode plugin
as well as some of our users reported this with the Ghostery Plugin.

We could reproduce the problem locally on dev mode/localhost as well as on the demo page with the dark mode plugin on Firefox 116.0.3. On my settings we could not reproduce the problem with the ghostery plugin

To Reproduce
Steps to reproduce the behavior:

1. Install the dark mode plugin or any similiar plugin (you must not if it concerns your security settings or you are unsure if this impacts your system.)
2. Call the page https://demo7.dspace.org/
3. Wait for the Loading - at the end some white page should occur
4. The Browser Console logs the following errors (won't paste the whole stack trace, but the relevant parts):

ERROR DOMException: CSSStyleSheet.cssRules getter: Not allowed to access cross-origin stylesheet
    h https://demo7.dspace.org/main.135b9dd6bfbbbfb9.js:1
    getCSSVariablesFromStylesheets https://demo7.dspace.org/main.135b9dd6bfbbbfb9.js:1
    storeCSSVariables https://demo7.dspace.org/main.135b9dd6bfbbbfb9.js:1

Unhandled Promise rejection: CSSStyleSheet.cssRules getter: Not allowed to access cross-origin stylesheet ; Zone: <root> ; Task: Promise.then ; Value: DOMException: CSSStyleSheet.cssRules getter: Not allowed to access cross-origin stylesheet
    h https://demo7.dspace.org/main.135b9dd6bfbbbfb9.js:1
    getCSSVariablesFromStylesheets https://demo7.dspace.org/main.135b9dd6bfbbbfb9.js:1
    storeCSSVariables https://demo7.dspace.org/main.135b9dd6bfbbbfb9.js:1

Expected behavior
We except the page to be loaded correctly.

Investigation
Our investigation come to the conclusion, that the stylesheets injected by external plugins (into the dom) can lead to problems when the stylesheet contains no cssRules and thus the stylesheetobject has no css rules.

The line where the error occurs is this

dspace-angular/src/app/shared/sass-helper/css-variable.service.ts

Line 102 in 77e994d

[...sheet.cssRules].filter(this.isStyleRule).reduce((propValArr, rule: any) => {

Possible Solution
One possible solution could be to add some additional filter in

dspace-angular/src/app/shared/sass-helper/css-variable.service.ts

Line 97 in 77e994d

.filter(this.isSameDomain)

which checks whether the stylesheet contains some cssRule property before processing the variables

Related work

This was introduced in 7.5 with commit 89ba24f (#1853) and should occur on 7.5 and 7.6 instances.

[tdonohue]

@floriangantner : Thanks for the detailed analysis. I agree this would be nice to fix if possible, to avoid odd behaviors if a user happens to have these browser plugins installed.

If you wanted to create a PR with your "Possible Solution" we could have others try it out and see if it works for them as well.

Moving this to our 7.6.x maintenance board and flagging as needs a volunteer in the meantime. PRs welcome though.

[ybnd]

I've been seeing this in my Firefox as well, even with plugins disabled.
It only seems to happen with some themes; like the dspace theme on https://demo.dspace.org/

[tdonohue]

Reopening, as #2454 had to be reverted in #2558 since it caused the bugs noted in #2557 .

Unfortunately, this would need more work to resolve. Perhaps an updated version of #2454 will provide better behavior overall.

For now, we may have to continue to ask users to disable problematic Browser Plugins (like Ghostery, etc), which is alkso sometimes the recommendation on StackOverflow: https://stackoverflow.com/a/62475347/3750035

[tdonohue]

NOTE: another possible option to solving this problem might be to see if there's a way to no longer use cross-origin stylesheets? I'm surprised we have any, as I thought all our stylesheets should be served from DSpace itself?

[tdonohue]

Further thoughts today. This problem might be related to this external Google font which is loaded into only the dspace theme: https://github.com/DSpace/dspace-angular/blob/main/src/themes/dspace/styles/_theme_sass_variable_overrides.scss#L6

That's the only place where I've found a possible cross-origin stylesheet. Maybe it could be fixed if we switched the dspace theme to using a font that doesn't require import? (Or alternatively distribute this Nunito font in the dspace theme directly instead of having to import it via URL... as all Google fonts are allowed to redistributed in other products.)

UPDATE: I found time to test this theory & I'm wrong. It's not the Google font which is to blame. I was able to reproduce this bug with Firefox + Dark Mode extension. Even if that Google font is removed, the error still occurs & references getCSSVariablesFromStylesheets here: https://github.com/DSpace/dspace-angular/blob/main/src/app/shared/sass-helper/css-variable.service.ts#L92

The error therefore appears to be coming from our own code.

[floriangantner]

Sorry about the circumstances and the late reply, i had time to further test it and reproduce it locally (also in dev mode) which leads to an more detailed error log (also see #2557 )

 NG03505: @slideSidebar has failed due to:
 NG03003: Please provide a value for the animation param sidebarWidth

The error after logging in (and hovering the admin sidebar

dspace-angular/src/app/admin/admin-sidebar/admin-sidebar.component.ts

Line 72 in 81e3b36

this.sidebarWidth = this.variableService.getVariable('--ds-sidebar-items-width');

) should occur because some variable --ds-sidebar-items-width is missing. The variables from _exposed_variables.scss https://github.com/DSpace/dspace-angular/blob/main/src/styles/_exposed_variables.scss seems to be unset after the stylesheets are filtered, so it should come from our own code.

Further investigating which stylesheets are being filtered by my proposed solution were also some stylesheets where (at least at the point of the request in the browser console) some cssRules were mentioned, but these were filtered.

It seems they have no own property "cssRules" but the cssRules are accessible/processed anyway. so some exception to catch the Unhandled Promise rejection: CSSStyleSheet.cssRules getter: Not allowed to access cross-origin stylesheet ; Zone: <root> ; Task: Promise.then ; Value: DOMException: CSSStyleSheet.cssRules getter: Not allowed to access cross-origin stylesheet error for external cross-origin stylesheets could solve the problem, although this looks a little bit odd for me.

  hasCssRules = (styleSheet) => {
    // Injected (cross-origin) styles might have no css rules value and throw some exception
    try {
      return styleSheet.cssRules;
    } catch (e) {
      return false;
    }
  };

[tdonohue]

Fixed (finally) in #2580