Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove all links, stylesheets and scripts added by the boot script when the client is unloaded #2782

Merged
merged 7 commits into from
Dec 3, 2020

Conversation

robertknight
Copy link
Member

@robertknight robertknight commented Dec 2, 2020

This PR fixes an issue where deactivating and re-activating the browser extension did not work properly after the recent addition of a new link[type="application/annotator+html"] element for the notebook. The problem is that the boot script checks for the existence of such a link and if found assumes the client is already active and bails out. There used to be a single link that was removed when the boot script was unloaded. Now there are multiple such links and only one gets removed when the client is unloaded.

The fix here is a general improvement to unloading of <link> and <script> tags added by the boot script when the client is unloaded. All such elements are tagged with a hypothesis-asset attribute by the boot script and then elements with this attribute are removed when the client is unloaded.

I also added a "Load client" / "Unload client" toggle button to the dev server to make it easier to test this without having to build the extension.

Ensure that all links, script and stylesheet elements added to the page
by the boot script are removed when the client is unloaded.

This fixes a problem where the recently added `<link>` for the notebook
app was not removed when the page was unloaded, causing attempts to
activate the browser extension on a page where the client had previously
been loaded and then removed, to fail.

The implementation works by tagging all elements with a
`hypothesis-asset` attribute in the boot script and then removing these
elements when the client is unloaded.
Add a button to the dev server to facilitate easy testing of unloading
and re-loading the client, as done by the browser extension and also
some third-party pages.
@codecov
Copy link

codecov bot commented Dec 2, 2020

Codecov Report

Merging #2782 (365c89a) into master (09a586c) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2782      +/-   ##
==========================================
- Coverage   97.74%   97.74%   -0.01%     
==========================================
  Files         202      202              
  Lines        7660     7659       -1     
  Branches     1693     1693              
==========================================
- Hits         7487     7486       -1     
  Misses        173      173              
Impacted Files Coverage Δ
src/boot/boot.js 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 09a586c...365c89a. Read the comment docs.

Copy link
Contributor

@lyzadanger lyzadanger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad you are addressing this (slash, whoops!) and it's headed in a good direction, but there are a few things that cropped up for me that I thought I'd get your feedback/response on before doing a full review:

  • On this branch running the dev server, the HTML test pages no longer work—they're throwing a TypeError on the missing toggle button reference
  • The custom attribute hypothesis-asset results in HTML that won't validate. Might we use a data- attribute or something else?
  • One of the goals of refactoring the dev server was to keep the serve-dev module relatively free of template literal strings. You might consider creating a new template file for the client-loading script that can be rendered/brought into context in the templateContext function and then referenced in the renderScript function string/literal template similarly to {{{hypothesisConfig}}} — I can provide some sample code for this if it helps?

The toggle button only exists on the index page. Also I fixed an issue
where an incorrect variable name went unnoticed due to DOM element IDs
creating global variables (sigh).
Adding a custom attribute without a `data-` prefix could potentially
cause headaches for publishers running their code through HTML
validation tools.
Per discussion on the PR, it is preferable to put markup and JS in the
dev server in external files rather than as string literals in
`serve-dev.js`. This enables them to be edited without having to restart
the dev server.

 - Extract shared functions for loading and unloading client into
   `scripts/util.js`

 - Move logic specific to the index template into `scripts/index.js`.
@robertknight
Copy link
Member Author

On this branch running the dev server, the HTML test pages no longer work—they're throwing a TypeError on the missing toggle button reference

🤦‍♂️ - Fixed! The logic for the toggle button is now in dev-server/static/scripts/index.js and is only loaded on the index page.

The custom attribute hypothesis-asset results in HTML that won't validate. Might we use a data- attribute or something else?

Yes, I've changed it to data-hypothesis-asset. While we don't apply HTML validation to the loaded application directly I can imagine that just maybe some user will want to run it on a page that has Hypothesis installed.

One of the goals of refactoring the dev server was to keep the serve-dev module relatively free of template literal strings.

Makes sense. I've moved the code for the toggle button into static/scripts/index.js and the shared code for loading and unloading the client into static/scripts/util.js.

This feature is now enabled by default.
@robertknight
Copy link
Member Author

On a related note, modern web specs support using <link> elements directly within a shadow root: whatwg/html#1572. I don't know which of the browsers we support actually support that though.

Copy link
Contributor

@lyzadanger lyzadanger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for perservering!

@@ -0,0 +1,16 @@
import { activeClientUrl, loadClient, unloadClient } from './util.js';

const toggleClientButton = document.querySelector('.js-toggle-client');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment/JSdocstring to this module to document its purpose?

src/boot/boot.js Outdated
const link = doc.createElement('link');
link.rel = rel;
link.href = url;
link.type = 'application/annotator+' + type;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious if we have a rough convention for when to use template literals or if it's up to the dev. Because of the literal + in this string, I'd personally find it easier to parse as

`application/annotator+${type}`

but this is quite trivial...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious if we have a rough convention for when to use template literals or if it's up to the dev.

We don't have a strong convention here. I'm happy to make this change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I want to emphasize that we don't need to :). Getting that micro-managey isn't something all that useful.

 - Add comment to explain purpose of `index.js`
 - Use a template string for readability
@robertknight robertknight merged commit 91f3648 into master Dec 3, 2020
@robertknight robertknight deleted the remove-all-links-on-unload branch December 3, 2020 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants