Bug 37697 - CSS from HTML customizations previews bleeds through to rest of page
Summary: CSS from HTML customizations previews bleeds through to rest of page
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: David Cook
QA Contact: Lucas Gass (lukeg)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-21 05:43 UTC by David Cook
Modified: 2024-11-15 20:23 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.11.00
Circulation function:


Attachments
Bug 37697: use shadow DOM for additional contents preview (2.20 KB, patch)
2024-08-21 06:00 UTC, David Cook
Details | Diff | Splinter Review
Bug 37697: use shadow DOM for additional contents preview (2.26 KB, patch)
2024-08-26 20:26 UTC, David Nind
Details | Diff | Splinter Review
Bug 37697: use shadow DOM for additional contents preview (2.32 KB, patch)
2024-08-27 17:29 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2024-08-21 05:43:07 UTC
Currently, code in the "Preview" for "HTML customizations" can impact the "/cgi-bin/koha/tools/additional-contents.pl?category=html_customizations" page which is... not good.

One suggestion is to use Shadow DOM to encapsulate the previews. I've used this elsewhere in Koha for maximum goodness.

We could also try iframes. 

One way or another, something needs to be done...
Comment 1 David Cook 2024-08-21 06:00:01 UTC
Created attachment 170519 [details] [review]
Bug 37697: use shadow DOM for additional contents preview

This change uses the declarative HTML style of Shadow DOM
to encapsulate the additional contents preview so that they don't
affect the main Koha page.

Test plan:
0. Create opacheader with following content:
<style>* { background-color: red }</style>
<p>This is awesome</p>
1. Note that most background-color in /cgi-bin/koha/tools/additional-contents.pl
is now red
2. Click "Preview content" for "opacheader"
3. Note that the background-color of the "p" in "opacheader" is red

4. Apply the patch

5. Refresh the page at /cgi-bin/koha/tools/additional-contents.pl
6. Note that the background-color is normal again
7. Click "Preview content for "opacheader"
8. Note that the background-color of the "p" in "opacheader" is red
Comment 2 David Cook 2024-08-21 06:02:38 UTC
If we really wanted to take this further, we could actually create OPAC and Staff Interface Template::Toolkit WRAPPER includes which more closely simulate an exact preview.

NOTE: Shadow DOM cannot include "html" or "body" elements, so any CSS/Javascript that relies on "body" elements won't work as expected.
Comment 3 David Cook 2024-08-21 06:03:01 UTC
Custom font-faces also don't work brilliantly with shadow DOM, but I know how to get around that, if you really care about that...
Comment 4 David Cook 2024-08-21 06:23:32 UTC
Martin pointed me at koha-tmpl/intranet-tmpl/prog/en/modules/members/notices.tt#L69 and that's an angle I was thinking about as well. Haven't had a chance to try out srcdoc yet...
Comment 5 David Nind 2024-08-26 20:26:44 UTC
Created attachment 170738 [details] [review]
Bug 37697: use shadow DOM for additional contents preview

This change uses the declarative HTML style of Shadow DOM
to encapsulate the additional contents preview so that they don't
affect the main Koha page.

Test plan:
0. Create opacheader with following content:
<style>* { background-color: red }</style>
<p>This is awesome</p>
1. Note that most background-color in /cgi-bin/koha/tools/additional-contents.pl
is now red
2. Click "Preview content" for "opacheader"
3. Note that the background-color of the "p" in "opacheader" is red

4. Apply the patch

5. Refresh the page at /cgi-bin/koha/tools/additional-contents.pl
6. Note that the background-color is normal again
7. Click "Preview content for "opacheader"
8. Note that the background-color of the "p" in "opacheader" is red

Signed-off-by: David Nind <david@davidnind.com>
Comment 6 Lucas Gass (lukeg) 2024-08-27 17:28:27 UTC
I used something like this to test: 

<style>
  body, h1 { background: red!important }
</style>

<h1>TEST</h1>

<script>
  console.log('HELLO WORLD!');
</script>


-It stops the CSS from rendering on additional-contents.tt! 
-I still get a HELLO WORLD in the console. Probably a separate bug? 
-HTML validator gives me this: 

Error: Attribute shadowrootmode not allowed on element template at this point.

But I don't think that is a blocker, browsers seem to support this now: https://caniuse.com/?search=shadowrootmode


This is a nice improvement as the additional-contents.tt page can look quite insane when it renders that CSS!
Comment 7 Lucas Gass (lukeg) 2024-08-27 17:29:03 UTC
Created attachment 170780 [details] [review]
Bug 37697: use shadow DOM for additional contents preview

This change uses the declarative HTML style of Shadow DOM
to encapsulate the additional contents preview so that they don't
affect the main Koha page.

Test plan:
0. Create opacheader with following content:
<style>* { background-color: red }</style>
<p>This is awesome</p>
1. Note that most background-color in /cgi-bin/koha/tools/additional-contents.pl
is now red
2. Click "Preview content" for "opacheader"
3. Note that the background-color of the "p" in "opacheader" is red

4. Apply the patch

5. Refresh the page at /cgi-bin/koha/tools/additional-contents.pl
6. Note that the background-color is normal again
7. Click "Preview content for "opacheader"
8. Note that the background-color of the "p" in "opacheader" is red

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 8 David Cook 2024-08-27 23:47:18 UTC
(In reply to Lucas Gass from comment #6)
> -It stops the CSS from rendering on additional-contents.tt! 
> -I still get a HELLO WORLD in the console. Probably a separate bug? 

Javascript isn't encapsulated quite to the same degree as CSS. The Javascript still has access to globals like "console", events (like mouse clicks) still bubble up, and I think there are some other ways Javascript can still interact/conflict. 

An iframe-based solution would be better than this one, although I think using shadow DOM here is certainly an improvement in any case. Perhaps a stepping stone to a more complicated iframe-based solution.
Comment 9 Katrin Fischer 2024-08-29 15:25:19 UTC
Pushed for 24.11!

Well done everyone, thank you!