app/assets/javascripts/errorTracking.js sent
events to `window.ga`.
This extends the API of `window.GOVUK.Analytics`
to include support for sending events so all
calls to `window.ga` can use it instead of direct
access.
This use of `window.ga` was missed from the
initial work on `window.GOVUK.Anaytics`.
Includes:
- new content
- added option to turn analytics on/off
- non-js version for the on/off switch
- a banner to confirm user's choice was saved,
shown when they click the save button
- the cookie banner that appears on all other
pages removed from this page
Removes the following cookies:
- seen_cookie_message (flags if banner was already
shown)
- _gid (Google Analytics cookie)
- _ga (Google Analytics cookie)
These were set by default before so potentially
still around for some users.
The code for this now exists as a static method on
the cookieMessage module and is called when the JS
loads for the first time.
Copies HTML and Sass from GOV.UK Pubishing
components cookie-banner with changes to content
and functionality to better suit Notify.
Changes are:
- adds a 'reject' button which the GOV.UK
code doesn't have
- adds Sass from the GOV.UK Frontend button
component which the GOV.UK version used so
is included here
- removed click tracking from cookie banner
Their priority should always add up to 100%. Currently we have to ensure
this by hand. Adding this form means there’s no way to not set their
combined priorities to 100%. And it’s a bit more of an intuitive UI than
two textboxes on separate pages.
The current method reports `0` in Safari, whatever
the scroll position.
Some testing across our browser matrix shows:
1. this is also the case on IOS
2. browsers in the matrix all support
`$(window).scrollTop()`
https://scroll-position-test-page.glitch.me/#results
This changes the method to use
`$(window).scrollTop()` instead.
Means our rollup bundling doesn't leave any
artefact files lying around that we'd then have to
deal with.
Also includes:
- removal of some JSHint config' marking the
artefacts as scripts to ignore
- use of streamqueue package to allow the same
ordering of scripts as before
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
Means our rollup bundling doesn't leave any
artefact files lying around that we'd then have to
deal with.
Also includes:
- removal of some JSHint config' marking the
artefacts as scripts to ignore
- use of streamqueue package to allow the same
ordering of scripts as before
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
Means our rollup bundling doesn't leave any
artefact files lying around that we'd then have to
deal with.
Also includes:
- removal of some JSHint config' marking the
artefacts as scripts to ignore
- use of streamqueue package to allow the same
ordering of scripts as before
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
HighlightTags was bad because:
- we haven’t called placeholders ‘tags’ for a long time
- it also does resizing of the `<textarea>`, not just highlighting the
placeholders
Scrolling within textareas on the page is a bit grim. Which is why we
don’t do it for the textboxes that people use to edit templates.
This commit will allow us to extend the auto-resizing of `<textarea>`s
to those which don’t need the highlighting of placeholders.
The code is still quite coupled to the placeholder highlighting code,
because both work by copying the content of the `<textarea>` into a
`<div>` that underlaps the textbox. This `<div>` is used for both
rendering the placeholder highlights, and calculating the natural height
of the content. So it would be hard/confusing to split the two bits of
code into separate modules.
This is mainly because tests don't inferr that
global variables are just properties of the window
object, as browsers do, but it also makes this
more explicit.
When testing with the JAWS screenreader, we found
a bug around getting it to announce the name of a
fieldset when we ask the user to select from it.
Bug on pivotal:
https://www.pivotaltracker.com/story/show/165565088
The flows for adding a new template and moving a
template/folder both need the user to select an
option from a radio group. When we add the radio
group to the UI, we need to move focus to it so
the user is in the right place to choose an
option.
The expectation of the original code was that
focusing the field set's legend would work like
focusing the heading of a section of content and
announce the label of it. This didn't happen with
JAWS. This tries to achieve the same by focusing
the whole fieldset instead.
When doing this we also hide the focus style, to
follow the convention for this across www.gov.uk.
`clearEvents` helps write the tests and also gives
users the opportunity to remove all of this
functionality.
Refactor of `setEvents` tidies up use of `self`.
