Skip navigation
All Places > Ideas > Blog > Authors Jon Fenton


4 Posts authored by: Jon Fenton Administrator

Enhancing our stylus support in SpeedGrader to include Windows touch-enabled devices has been an exciting and challenging journey. We’ve learned a lot along the way, and I wanted to share a few thoughts. We hope this will provide insight into why we’ve implemented stylus support the way we have.


When a user touches the screen in SpeedGrader, we get touch or pointer events from the browser that tell us if a user is using a stylus or a finger. These events differ from one browser to the next, as well as what we can do with them.


To normalize the behavior across different browsers and different annotation types, we decided to use the physical button on the stylus as the trigger for annotating. When the user was holding down the button, we knew to lock the page (so that it wouldn’t scroll) and to start annotating when they touched the screen. When the user released the button, we would use the touch events to scroll the page.


We genuinely appreciate all the feedback we’ve received on this approach and have made some changes intended to make using a stylus more comfortable and natural. Given the nature of browser interactions (including the difference I mentioned above), this new experience will not be quite as uniform as when the button was required to annotate.


Let me take you through our new approach.


For highlight and strikeout annotations, pressing the button is still required in all browsers. We rely on the browser sending us a section of selected text to know where to place these annotations. This should feel familiar to stylus users, as highlighting text OS-wide requires a button press.


All other annotation types can be used without the button. Simply select the annotation type and touch anywhere on the document to begin annotating. In Chrome users can scroll with their finger while in any annotation mode. This should make it seamless to alternate between annotating and scrolling.


There are two limitations with the current version of Edge. First, pointer events are registered relatively slowly, making it difficult for us to lock the page before a user starts writing with the pen. This can cause the page to scroll as the user is annotating. To prevent this, we’ve disabled the ability for users to scroll with their finger while in an annotation mode. Secondly, there is currently a bug within Edge that prevents users from using the scrollbars with a stylus under certain circumstances. We’ve had conversations with Microsoft around both of these limitations and they’re exploring possible solutions.  


Support for the upcoming Chromium-based version of the Microsoft Edge Browser is already in place. It does not have the limitations that the current version of Edge does, meaning that users can scroll with their fingers in every annotation mode. You can check out the developer preview here.


Firefox continues to have limited stylus support in SpeedGrader. Firefox pointer events are disabled as soon as a user touches the screen, meaning we can only get touch events. This makes it very challenging for us to distinguish between a stylus and a finger. Additionally there are several known bugs that limit our ability to build out stylus support.


We hope that these changes will make it more natural to annotate with a stylus. This has been a collaborative effort with Microsoft and we appreciate their support and feedback.


As always, let us know what you think in the comments.

Last October we outlined a new security project for Canvas that gives institutions more control over the javascript that is allowed to run in their instance of Canvas through an updated Content Security Policy (CSP). We've been working hard to make this plan a reality and I'd like to post an update on our progress.


This project is comprised of three phases. The first phase changed the way we were serving up files in Canvas. The goal of this phase was twofold:

  • Make it clear that the files are not owned by Instructure, but rather by other Canvas users.
  • Limit how broadly user-granted permission was being applied. For example, if a user grants a file permission to access their webcam, permission will only be given for files in that course, and not for all files in that institution's instance of Canvas.

This first phase was deployed at the end of the year (view release notes here).


The second phase brings an updated CSP option to Canvas. The updated CSP will be opt in from a new Security Tab found on the account settings page. Institutions that don't opt in will have no changes made to their account. If an institution does choose to enable the updated CSP they will be able to restrict custom JavaScript (JS) that runs in their instance of Canvas based on domain.

  • This will be managed by a whitelist of acceptable domains. All JS that attempts to execute in violation of the whitelist will be blocked.
  • The whitelist has a limit of 50 domains. We recommend using wildcard domains (*.domain).
  • We will automatically add all necessary Instructure and Canvas domains, as well as any LTI tools that are configured on the account. These do not count toward the 50 domain limit.
  • Root account admins determine if sub accounts can manage their own whitelists. If so, sub accounts will have the option of either inheriting the whitelist from the parent account or managing their own whitelist.
  • Individual courses can be opted out of the CSP (for example, a computer science class that requires the ability to render student-submitted JS). Only account admins can opt a course out of the CSP.

This phase is currently in development. Our plan is to have this phase completed in the next couple of months.


The third phase adds a log to the UI which shows any requested domains that are in violation of the whitelist. This will allow admins to monitor activity and easily add new domains to the whitelist.

This phase is currently in the design stage and will begin development after phase 2 is released.


We're excited about the increased control this gives to institutions in managing the security for their instance of Canvas. As always, we'd love to hear from you. Let us know what you think in the comments!

We previously posted to the community a proposal for a new security policy in Canvas. In that post, we discussed the open nature of Canvas and our desire to make Canvas as flexible as possible while still implementing good security practices. Balancing security with flexibility is a task that we take very seriously, and we’re constantly reviewing and improving our approach and stance. As the world changes, we make adjustments when needed. At that time, we proposed a change to Canvas that would limit custom JavaScript from running in the Files section of Canvas.


We received a lot of great feedback from the community and we appreciate everyone who contributed. After additional discussion and research, we decided that a more comprehensive solution was needed. We've been working since then on a new approach that we would like to announce today. This new project will be completed in 3 phases:


Phase 1 -  Serve user files from non-application domain

  • Change the files domain from to This will make it clear that the files are not owned by instructure, but rather by other canvas users. Users will most often see this domain when browsing files in the Files section of Canvas, or when a file requests a user’s permission.
  • Change the files subdomain from clusterXX-files to one based on the associated account and course of the file being served. This change will mean that when a user grants a file permission (to access a users webcam, for example) permission will only be given for files in that course, and not for all files in that institution.


Phase 2 - Allow domain whitelisting

  • Allow institutions to restrict custom JavaScript (JS) that runs in their instance of Canvas based on domain. This will be enabled by an updated Content Security Policy (CSP) from Instructure. Institutions will have the option to enable the new CSP as a setting at the account level. The new CSP will be opt-in, and institutions that choose not to enable it will have no changes to their account.
    • Once the updated CSP is enabled, institutions will have a whitelist of acceptable domains that they maintain. We will automatically populate the list with all of the Instructure domains.
    • Individual courses can be opted out of the CSP (e.g., a computer science class requiring the ability to render student-uploaded JS).
    • All custom JS that is in violation of the whitelist will be blocked from running.


Phase 3 - Surface CSP violations to administrators

  • We will present administrators with a log of any requested domains that are in violation of the CSP. This will allow them to monitor violations and update their whitelist as needed.


We believe this approach will give Canvas administrators fine-grained control over the security for their institution while also preserving flexibility. Our preferred approach is to make this change as part of our standard deployment process—first to beta where it can be evaluated by admins, and then to production. We plan on each phase being deployed independently. Work has already begun and we currently estimate that we will have Phase 1 completed in Q4, 2018, Phase 2 completed in Q1, 2019, and Phase 3 completed in Q2, 2019.


As always, we would love to hear your thoughts and feedback. 

Jon Fenton

Reflecting on DocViewer

Posted by Jon Fenton Administrator Aug 21, 2018

Hello, everyone!

Many months ago, we outlined our plans for DocViewer from your input, and we have been working hard to deliver the items laid out in our plan. We are so grateful for the feedback we’ve received from the community as we work to make DocViewer even better. Your suggestions and ideas have been crucial in laying out the path.


We recently completed the final request on this list of most needed features. While we’re focused on the future of DocViewer and adding even more functionality, I thought it was worth taking a minute to reflect on some of the most recent improvements as we cross this milestone.  


This list isn’t exhaustive, and it doesn’t include the many back-end changes that have happened behind the scenes. As always, you can head over to the Canvas release notes for more information.


Recent DocViewer Changes


Annotation Comment Icons

Icons have been added to annotation comments, right next to the name. In order to keep things from getting too cluttered, the icon is only displayed next to the first comment and not on any replies made to that comment.


Ink Stroke Width Controls

Free draw annotations include three stroke widths. Or, in other words, you can now make your checkmarks, smiley faces or intricately drawn characters as subtle or as in-your-face as you need to. Go crazy.


Non-Author Annotation Comments

Previously, only the author of an annotation could make the first comment. This meant that other users who wanted to leave comments on an annotation could only do it if the author had already left a comment. But no more! Now any user can leave the first comment on an annotation.


Instructor Annotation Management

Ever had someone leave an annotation or comment that you didn’t approve of? Yep, so have we. It was driving us (and many of our users) crazy that only the author could delete an annotation or comment. So we fixed it! Instructors can now delete any annotations or comments for any user. This ability also applies to any custom role that is based on the teacher role.


Comment Truncation at 5 Lines

We’ve extended the amount of text that shows on a comments to 5 lines. Previously, comments were truncated after just 1 line, which made getting context and browsing comments tricky. Displaying 5 lines should help with that. As always, when you click a comment, the full comment is expanded.


Comment Display Order and Padding

When users click comments within a submission, comments retain their vertical order when the comment is aligned with an annotation. Additionally, padding around the comments has been reduced so there’s less wasted space.


Image Support

Drumroll please! DocViewer supports comments and annotations on BMP, JPEG, JPG, PNG, TIF, and TIFF images! Large images (or insanely massive 5k images—I’m looking at you photography instructors) are automatically scaled to a lower resolution so that the entire image can be displayed.


Limit Comments to a Single Page

The comment area is scrollable and reveals any comments that don’t fit on the page. And of course, clicking an annotation or comment will align the comment to the associated annotation.


Anonymize Instructor Annotations Setting

This assignment setting replaces instructors’ names with “Grader” when they leave annotations and annotation comments. For the purposes of this setting, we identify instructors as any role that has the “Grades - Edit” permission enabled.


All right, so that’s a recap of some of the recent changes to DocViewer. We’re excited for the future of DocViewer and appreciate all of your support. As always, please keep the great feature suggestions and feedback coming. We're excited to keep making DocViewer even better.




Engineering Note

The lead engineer for DocViewer wanted to use this milestone as an opportunity to add a few of his thoughts and comments from the technical team.


My reflections as the tech lead for the DocViewer project.


I first came to this project in September of 2017 and immediately was blown away by the skill and conscientiousness of the team I’ve been privileged to lead. From day one, it was very clear that the engineers were all very interested in improving the user experience of DocViewer for all of you. I’ve never been involved with a team that had such a customer focus in my 25+ year career.


This customer focus sometimes drives intense conversations about the right thing to do, since we are all opinionated about what makes a great experience, but we always arrive to a conclusion with changes we know will have a good chance at positively improving your experience.


And that’s what drives us: you. Sure, we are all technologists who enjoy working with and expanding on the latest technologies and this project allows us to explore that technical itch. (For example, a partial list of the languages and technology we use to bring you DocViewer includes AWS, Node, Javascript, React, Java, DynamoDB, Scala, Jenkins, Puppeteer, SQS, LibreOffice, and Docker. But even the full list with all its geeking potential pales in comparison to what providing a great experience for y’all means.)


When we get something right by you, we celebrate as a team as we read your comments and thanks. When we come up short, our first instinct is to understand how we can make things better.


Thanks, y’all, for taking the time in telling us what you need, and thank you for expressing your thanks to us. We feel honored to be a part of your success with Canvas. I’m looking forward to seeing what we, together, come up with next!