Leading through Chaos - Insights and Actions • Browse the resources from the keynote presented by the Academic Strategy Team.
Apologies if this has been asked elsewhere, but in trying out the new "Pretty HTML" feature, I have been unable to paste text using keyboard shortcuts. So, my questions are as follows:
Solved! Go to Solution.
For the people with issues, are you using touchscreen computers/laptops?
@KOliveras I took a further look at the CodeMirror.js file and from the way is written, we should only get the emacs bindings (which are one of the 2 fallthroughs in keyMap.macDefault) in the case where mac is true in this statement.
keyMap["default"] = mac ? keyMap.macDefault : keyMap.pcDefault;
mac is defined as:
var mac = ios || /Mac/.test(platform);
So, it's true iOS if true or platform has Mac in (platform is a variable that is equal to navigator.platform, which you can run in your web console. Mine evaluated to false).
Next, iOS is defined as:
var ios = !edge && /AppleWebKit/.test(userAgent) && (/Mobile\/\w+/.test(userAgent) || navigator.maxTouchPoints > 2);
Which is true is your userAgent doesn't have "Edge" in it (that's what edge checks for, and Chrome doesn't), if your userAgent has AppleWebKit in it (which Chrome does, but Firefox does not), and if your useragent has mobile in it (Chrome doesn't) OR it has a navigator.maxTouchPoints > 2.
In my laptop that isn't working, a touchscreen Windows 10 laptop, navigator.maxTouchPoints is 10. In the work-issued laptop, which is working properly, this is 1.
So, there are probably other issues, but it looks like one of them is that the code identifies us as iOS, and then Mac users, so defaults to the macDefault. The macDefault fallthrough probably tests some other aspects of Macs that we fail, so we get stuck with the eMacs ones. Ultimately then, this looks like a bug Canvas has to fix.
Thanks KOliveras. I have the same question - also in relation to search within the pretty HTML editor. I have a colleague who is able to paste with keyboard. He can also search, but only within the visible frame, which is a bit limiting. Any advice greatly received!
Copy/Paste code in the pretty html editor only seems to work in Firefox but not in Chrome.
I've been able to get it to work in both Chrome and Safari on iOS, but not via Chrome on the PC. Installing firefox now to test on a PC. Hopefully we can get some info about the keyboard shortcuts soon.
For what it's worth, if you are running a browser based on Chromium v89 (in beta), then using CTRL+V operates like "Page Down"
Ctrl+F to find things also does not work in Chrome. By this I mean, if your cursor is in the text box, the Ctrl+F command does not work at all.
If it is outside the text box, the command works - but it doesn't actually find all the matching instances (this is the case in both Firefox and Chrome). It seems to only find instances that show in the "visible" portion of the text box, unless you go into full-screen mode.
I usually use Edge but have tested in Chrome and still can't get them to work (although Ctrl+F outside the box may find what's visible, as you mention and-hu, but that's pretty useless).
KOlivers, it's useful to know CTRL+V acts as page down (I hadn't really picked up on that and thought it was jumping around randomly) - but only in the pretty editor and not in the raw, where it works to paste as expected.
Unfortunately at the moment lack of keyboard shortcuts in Edge/Chrome makes pretty html editor un-usable for me which means I' now have an extra click to raw html editor to get anything done. Fingers crossed that this will be resolved soon, because I'd love to be able to work in the pretty editor 🤞
Thank You for posting! I am so excited about the new look of the HTML editor, but when the shortcuts weren't working, I immediately searched the Question Forum to see if I was the only one. I am happy that I can jump to Firefox for HTML in the meantime, but I look forward to having everything in one place in Chrome someday.
I'm not seeing these issues. That doesn't mean they're not happening to you, but it lets us know it's not a universal problem (like the MathJax pull was) and suggests that there may be something else causing a conflict.
I'm using Chrome on a PC and can search anywhere (not just the visible source) using Ctrl-F. I can paste using Ctrl-V. I tested it in full screen mode and it worked there as well.
Have you tried this in incognito mode? There may be some extensions that is causing a conflict, especially those that have the ability to read the content of the entire page -- we ran into an issue last year where PDFs wouldn't load and disabling browser extensions (adblockers, coupon scanners like Honey, and a few other were bad) resolved it.
@James Thanks for the info. Knowing that it's working for someone on a PC with Chrome got me to dig into it a bit more. I tried disabling extensions/incognito mode, but unfortunatly, no luck. So I started digging around in the CodeMirror.js file. At the very least, I feel better about CTRL+V acting like a "page down". For what it's worth, here's what's listed for the keyboard bindings:
var keyMap = {};
keyMap.basic = { "Left": "goCharLeft", "Right": "goCharRight", "Up": "goLineUp", "Down": "goLineDown", "End": "goLineEnd", "Home": "goLineStartSmart", "PageUp": "goPageUp", "PageDown": "goPageDown", "Delete": "delCharAfter", "Backspace": "delCharBefore", "Shift-Backspace": "delCharBefore", "Tab": "defaultTab", "Shift-Tab": "indentAuto", "Enter": "newlineAndIndent", "Insert": "toggleOverwrite", "Esc": "singleSelection"};
// Note that the save and find-related commands aren't defined by
// default. User code or addons can define them. Unknown commands
// are simply ignored.
keyMap.pcDefault = { "Ctrl-A": "selectAll", "Ctrl-D": "deleteLine", "Ctrl-Z": "undo", "Shift-Ctrl-Z": "redo", "Ctrl-Y": "redo", "Ctrl-Home": "goDocStart", "Ctrl-End": "goDocEnd", "Ctrl-Up": "goLineUp", "Ctrl-Down": "goLineDown", "Ctrl-Left": "goGroupLeft", "Ctrl-Right": "goGroupRight", "Alt-Left": "goLineStart", "Alt-Right": "goLineEnd", "Ctrl-Backspace": "delGroupBefore", "Ctrl-Delete": "delGroupAfter", "Ctrl-S": "save", "Ctrl-F": "find", "Ctrl-G": "findNext", "Shift-Ctrl-G": "findPrev", "Shift-Ctrl-F": "replace", "Shift-Ctrl-R": "replaceAll", "Ctrl-[": "indentLess", "Ctrl-]": "indentMore", "Ctrl-U": "undoSelection", "Shift-Ctrl-U": "redoSelection", "Alt-U": "redoSelection",
"fallthrough": "basic"};
// Very basic readline/emacs-style bindings, which are standard on Mac.
keyMap.emacsy = { "Ctrl-F": "goCharRight", "Ctrl-B": "goCharLeft", "Ctrl-P": "goLineUp", "Ctrl-N": "goLineDown", "Alt-F": "goWordRight", "Alt-B": "goWordLeft", "Ctrl-A": "goLineStart", "Ctrl-E": "goLineEnd", "Ctrl-V": "goPageDown", "Shift-Ctrl-V": "goPageUp", "Ctrl-D": "delCharAfter", "Ctrl-H": "delCharBefore", "Alt-D": "delWordAfter", "Alt-Backspace": "delWordBefore", "Ctrl-K": "killLine", "Ctrl-T": "transposeChars", "Ctrl-O": "openLine"};
keyMap.macDefault = {
"Cmd-A": "selectAll", "Cmd-D": "deleteLine", "Cmd-Z": "undo", "Shift-Cmd-Z": "redo", "Cmd-Y": "redo", "Cmd-Home": "goDocStart", "Cmd-Up": "goDocStart", "Cmd-End": "goDocEnd", "Cmd-Down": "goDocEnd", "Alt-Left": "goGroupLeft", "Alt-Right": "goGroupRight", "Cmd-Left": "goLineLeft", "Cmd-Right": "goLineRight", "Alt-Backspace": "delGroupBefore", "Ctrl-Alt-Backspace": "delGroupAfter", "Alt-Delete": "delGroupAfter", "Cmd-S": "save", "Cmd-F": "find", "Cmd-G": "findNext", "Shift-Cmd-G": "findPrev", "Cmd-Alt-F": "replace", "Shift-Cmd-Alt-F": "replaceAll", "Cmd-[": "indentLess", "Cmd-]": "indentMore", "Cmd-Backspace": "delWrappedLineLeft", "Cmd-Delete": "delWrappedLineRight", "Cmd-U": "undoSelection", "Shift-Cmd-U": "redoSelection", "Ctrl-Up": "goDocStart", "Ctrl-Down": "goDocEnd",
"fallthrough": ["basic", "emacsy"]};
keyMap["default"] = mac ? keyMap.macDefault : keyMap.pcDefault;
@James Thanks for the info. I tried to reply earlier, but had some difficulty with posting. Knowing that it worked for someone got me to look more into issues on my end. Unfortunatly, disabling extensions/incognito mode didn't help.
I was able to look a little more into the CodeMirror.js file. Honestly, I haven't dived into it, but at least the emacs keyboard bindings listed in the file reminded me that CTRL+V and CTRL+SHIFT+V as page down and page up is something I should have recognized.
@KOliveras I have not seen an issue with Copy/Paste on my end. It worked okay for me. However, if there are updated Keyboard Shortcuts, that would be good to see.
For @and-hu and @jnc, I just created a Feature Request regarding the Ctrl-F issue. It is waiting for review.
@James I had tried the suggestion you mentioned about turning off extensions in Chrome. That does not fix the Ctrl-F issue for me. That also seems an odd fix considering Ctrl-F works fine in the Raw Editor despite using extensions. If it works in the Raw Editor, but not the Pretty Editor, that would imply something different about the Pretty Editor is causing the issue. Users should not have to make changes in their browser every time they switch from Raw to Pretty. Also, switching to Incognito mode did not correct the issue with Ctrl-F. If that helps you to know what I am seeing on my end.
For the people with issues, are you using touchscreen computers/laptops?
@KOliveras I took a further look at the CodeMirror.js file and from the way is written, we should only get the emacs bindings (which are one of the 2 fallthroughs in keyMap.macDefault) in the case where mac is true in this statement.
keyMap["default"] = mac ? keyMap.macDefault : keyMap.pcDefault;
mac is defined as:
var mac = ios || /Mac/.test(platform);
So, it's true iOS if true or platform has Mac in (platform is a variable that is equal to navigator.platform, which you can run in your web console. Mine evaluated to false).
Next, iOS is defined as:
var ios = !edge && /AppleWebKit/.test(userAgent) && (/Mobile\/\w+/.test(userAgent) || navigator.maxTouchPoints > 2);
Which is true is your userAgent doesn't have "Edge" in it (that's what edge checks for, and Chrome doesn't), if your userAgent has AppleWebKit in it (which Chrome does, but Firefox does not), and if your useragent has mobile in it (Chrome doesn't) OR it has a navigator.maxTouchPoints > 2.
In my laptop that isn't working, a touchscreen Windows 10 laptop, navigator.maxTouchPoints is 10. In the work-issued laptop, which is working properly, this is 1.
So, there are probably other issues, but it looks like one of them is that the code identifies us as iOS, and then Mac users, so defaults to the macDefault. The macDefault fallthrough probably tests some other aspects of Macs that we fail, so we get stuck with the eMacs ones. Ultimately then, this looks like a bug Canvas has to fix.
Wow! Thanks @and-hu This is incredibly helpful information! I was a bit too tired last night to look into this and was planning on looking at it this morning. What a great way to wake up and see that someone else had done it (and documented it far better than I could) :D. MANY THANKS!
And yes, all of my PC’s have multiple touch points.
@and-hu - That's it! Copy/Paste works just fine on my work laptop, but not my personal (Acer Spin) which has a touch-screen. Thanks for sharing back!
@Stef_retired Is the team currently working on this? It seems like there have been a few changes over the last 24 hours and I'm getting very different behavior than when I originally posted the thread. I’m currently trying to reply to discussion posts on my Canvas site using the pretty html editor, and now simply typing “d” (without CTRL, ALT, or any META keys) attempts to delete the post.
I will follow up re support (Win 10, Chrome, Multi-Touch).
@KOliveras I recommend that you initiate a support case for this; I'm not able to replicate the behavior you've described.
Just an update on this piece of the puzzle related to editing discussion posts using the pretty html editor, I opened a support case and L3 support was able to replicate the issue with editing discussion posts. Here's the reply that I received in case anyone else was curious about this specific behavior:
I have been doing testing on this issue with a Windows 10 Surfacebook pro and did replicate the issue. I also did some other testing and found that the D and N keys can do the same thing on non touch screen devices but only if you click outside of the editor to make it lose focus. So I think that the problem is that there is a dual focus on the browser with these touch screen devices that is being recognized. I've mentioned this on the case and have escalated this to product and engineering for further review. Thank you for all the information and testing on your end as well. We will be notifying you via this case with more information once a fix is made available.
Hi @Stef_retired Stefanie
I initiated a support request several days ago and received a response this morning that was unhelpful to say the least. The suggestion that it must be browser when the functions work fine on raw editor and on all other activities within that browser really doesn't help (and makes no sense to me) - nor does the suggestion to search one segment of the pretty html editor at a time. I've responded to try to escalate, but even though I included a link to this thread it seems the support responder did not look at it.
Hello Julie
Thank you for your patience regarding the issue you see within the Pretty HTML editor.
Looking into this issue, I was able to see where you're seeing the issue when searching in the Pretty HTML editor. However, the keyboard shortcut cmd+f or ctrl+f is a function of the browser, not of Canvas. Depending on how each browser is configured it may read the information differently. I was able to see if you scroll through the HTML and then use the search function, more results do appear.
If you have more questions or need anything else, please let us know.
We've had a number of support agents and engineers investigate the behavior, and their consensus is that the ctrl-f search issue is indeed endemic to the browser configuration. That said, I don't have anywhere near the technical expertise to explain why that is—like you, I'd think it reasonable to expect that if the function works in the raw editor in your browser, it should also work in the pretty editor in that same browser—so I'm hoping to find someone who can provide additional detail.
The current recommendation is to use Firefox when using the pretty editor, or switch to the raw editor, when conducting a ctrl-f search for content.
I am also having issues with the Ctrl+F behavior in Firefox on Windows, it simply does not work properly in any browser I am using unless I make the Pretty HTML editor fullscreen.
Though, even if it did work in Firefox, since Chrome (and Chromium-based derivatives) is the most popular browser in the world by far, I would think it not working on Chrome would be a priority for Canvas to fix.
@jnc and @Stef_retired I also received such an email yesterday morning. I agree that it seems a rather unhelpful response and seemed to focus more on how it is someone else's issue. I had the same thoughts as you. This is not happening in the RAW editor. I also added that using another cloud-based programming website did not have this same issue. That another service and the RAW editor do not have such issues, it would imply that it has something to do with how Canvas's Pretty Editor interacts with browsers. That would make it a Canvas issue, not a browser issue. I also added that the Pretty Editor seems to autoscroll to the top of the editor EVERY TIME I navigate away from it, including merely going to another browser tab.
Either way, I would hope that Canvas would expect it's product to be usable as intended regardless of the browser being used.
@JeffCampbell We've brought the autoscroll issue to the attention of the product manager for the Rich Content Editor for further investigation, and in the meantime are asking users to initiate separate support cases for that behavior.
We do appreciate your efforts to help improve the functionality of the editor through communication with the development team and techs. Thank you @Stef_retired
Folks, thanks for your posts. I was, first, quite excited just to see this implementation. Pretty is nice.
I can confirm full functionality of CTRL-C, -V, -Z, -F using Firefox on a Windows 10 machine.
I think @and-hu suggested that the issue seems to be related to whether your computer was touch screen rather than the browser or OS; I'm working on a touch screen and a colleague of mind (who can use all shortcuts - except that Ctrl+F still only works on visible screen) is not on a touch screen. But it's confirmation again that it's not the browser that seems to be the issue as the responses to support requests keep trying to suggest.
I also have the same keyboard shortcuts issues reported by @and-hu and @jnc , specially with CTRL + F. This is very frustrating because in our institution we use this shortcut a lot as we create the pages. Anyway, as @JeffCampbell said, Ctrl + F works fine in the Raw Editor. So, it's sad, but we are using Raw Editor despite the Pretty Editor looks, actually, prettier. I hope Instructure can fix this issue in the next release.
Once again @JeffCampbell and @Stef_retired I received an unhelpful email response last night:
"Thank you for the reply back to us. I'm sorry that the search function in Chrome and Firefox don't support searching within HTML elements. When you search for this within the page and it shows some results, that is because the HTML has been rendered for what is actively being displayed on pages. In order to implement a way to search through the HTML in the Pretty HTML Editor, it would require a new feature implemented that specifically searches through the HTML of the page. Since you already have the feature request already created, https://community.canvaslms.com/t5/Idea-Conversations/Pretty-HTML-Editor-Ctrl-F-Won-t-Work/idi-p/447... then you may be able to add your comments on this to that request to show more support for this to be developed quicker."
It seems that in the other thread similar non-response responses have been received - in particular, blaming the browser when Ctrl+F works fine in RAW editor. They also didn't address related concerns about Ctrl+V not working (or rather acting surprisingly as a page-down).
I'll just keep using RAW as it seems they are not interested in fixing it or are not able to fix it.
For everyone who has been participating in this conversation, we thank you for your patience. Our engineering team has now created a ticket to investigate the keyboard shortcut issue in Pretty HTML, so if you've already submitted a support case, please reply to to the ticket with a request to have your case associated with the engineering ticket—and if you haven't yet initiated a case, please do so in order to receive direct updates and to provide our engineers with additional evidence that will help them in the investigation.
Would super appreciate it if anyone who has support tickets out keeps us up to date on progress! I have had such nightmare experiences with the "experts" at Canvas support, I just cannot subject myself to them again.
For what it's worth, the CodeMirror devs identified this issue and deployed 5.59.1 to fix it (current version is 5.60.0). Canvas is still using 5.59.0. So, I guess whenever Canvas gets around to updating CodeMirror is when it'll be fixed.
Thanks for the update @and-hu
I was directed to this discussion by a support agent: We observed a different type of discrepancy with the raw vs pretty html editor, in that simply using the pretty html editor and saving a page will modify the html in unanticipated ways.
Here are the steps to replicate:
Paste this text into a page using the raw HTML view:
<p>Module<a title="Module 1" href="https://bcourses.berkeley.edu/courses/1506659/pages/module-1" data-api-endpoint="https://bcourses.berkeley.edu/api/v1/courses/1506659/pages/module-1" data-api-returntype="Page"><span class="screenreader-only">Module </span>1</a></p>
Save the page.
Edit the page: using the RAW html view, change the word "module" to "week" e.g.
<p>week<a title="Module 1" href="https://bcourses.berkeley.edu/courses/1506659/pages/module-1" data-api-endpoint="https://bcourses.berkeley.edu/api/v1/courses/1506659/pages/module-1" data-api-returntype="Page"><span class="screenreader-only">Module </span>1</a></p>
Save the page, and confirm that the text was updated, and nothing else changed.
Now, edit the page again using the pretty html editor. Change the word "week" back to "module" and save.
Notice that a hyperlinked space has been added between the word "module" and the href "1"
This is a random piece of html out of context, but it's the simplest example I could generate of a formatting issue that is messing up complex, accessible layouts.
@Stef_retired Has there been any update on the status of this bug? I noticed when looking at the "Known Issues" that this bug isn't even listed, which is worrying. Especially since this is a bug that has actually already been fixed by the third-party creators.
@and-hu Please request updates directly through the case.
I noticed today that this bug now seems fixed; and that Code Mirror is now on version 5.61.1. 😁 Very happy this was updated before I had to really work on the bulk of my pages.
To interact with Panda Bot, our automated chatbot, you need to sign up or log in:
Sign inTo interact with Panda Bot, our automated chatbot, you need to sign up or log in:
Sign in
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.