Pretty HTML Editor - Ctrl F Won't Work

0 Likes
(10)

In exploring the "Pretty" HTML Editor, I have found that using Ctrl-F to find elements on a page does not work properly. This slows down use of an editor that has visual benefits when designing pages.

I have a test page I've been using to test something I was working on to get the look right. The page has several different versions of a common list, resulting in 35 individual list elements. I use Ctrl-F a lot to look for specific things when editing to more quickly make specific edits. When I do a search for <li on the Raw Editor, there are 35 instances on the page. If I switch to the Pretty Editor, it only finds 13. It seems to focus only on the elements visible on the page, plus a few extra (the extras almost match what would be seen if you hit Page Down once). On normal pages, where I might have specific marker text to search for, Ctrl-F won't find it because it is too far down the page. 

That the ability to search in the Pretty Editor is so drastically hindered makes using the it a bit more cumbersome. Hopefully, this is due to an error that can be corrected.

EDIT: I had tried turning off extensions in Chrome. That does not fix the Ctrl-F issue for me. Also, switching to Incognito mode did not correct the issue with Ctrl-F.

EDIT 2: Support Case Number 07378535

33 Comments
Stef_retired
Instructure Alumni
Instructure Alumni

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 this further, 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.

JeffCampbell
Community Contributor
Author

@Stef_retired Is there a ticket # that we can use when we send that reply to ensure the case gets attached to the correct ticket?

Stef_retired
Instructure Alumni
Instructure Alumni

@JeffCampbell Yes, you can ask the agent to associate your ticket with LS-2004.

JeffCampbell
Community Contributor
Author

@jnc I've also used Sublime Text (downloaded software) during my first attempt with learning Python. It also can display HTML. I toyed with it today. While it does not provide an automatic preview of the code like Codepen, it does provide a visible line going down the page to align related starting and ending tags. A seemingly basic but useful feature:

Sublime Alignment.PNG

dlyons
Instructure Alumni
Instructure Alumni
Comments from Instructure

Hello all! CTRL-F is working as expected in the PrettyHTML view again (as it should be!) We fixed it over the summer but a response never made it here to the Community. Sorry about that!

Stef_retired
Instructure Alumni
Instructure Alumni
Status changed to: Archived
 
James
Community Champion

David ( @dlyons ), awkward that you would announce this as fixed today. It may have been fixed back in the summer, but I noticed it was broken again last week. I checked again today and am seeing some really wonky behavior.

I have a lengthy page of notes for my student. If I search for the word "then", Chrome finds it 10 times when view the page, 10 times when editing the page in the rich text mode, 10 times when editing the page in the raw HTML mode, but only 3 times while editing in the pretty HTML mode.

If I toggle through the different modes and don't re-search, I can get it to say it found it 13 times in the pretty HTML mode, but it will only cycle through three of them using the next and previous buttons. I think that's a fluke of switching modes confusing the browser. If I re-search for "then", I get either 10 or 3.

If I am in pretty HTML editor mode, the number of times it is found depends on where I'm at on the page when I use the Ctrl+F. It may be 3 at the top, 1 in the middle, and 2 at the bottom. It is almost as if it searching the viewable content, plus a few lines on either side rather than the entire content.

It took me a while last week to figure out what was going on. I finally switched to raw mode to be able to find the things that needed changed.

dlyons
Instructure Alumni
Instructure Alumni

Hey, @James, it's only awkward if we let it be. 😉

It does, unfortunately, look like you're correct. The CTRL-F functionality finds the text and will properly scroll to it, but it appears to be reporting an incorrect number of occurrences. So at least it's a different issue than it was before. My guess is the text is still searchable when toggling between views which is where the weird additive count is coming from as that doesn't happen until the views have been switched between.

Two steps forward, and all that. We'll get on it!

James
Community Champion

@dlyons 

I'm not sure exactly what the issue is. To be clear, though, it is only scrolling to the text that it finds, which matches the count that it shows. I'm not concerned with it saying there are 13 occurrences when there are only 10; it's the only finding 3, and scrolling through the 3, when there are really 10.

When I encountered the issue last week, I was trying to clean up my content, including removing non-breaking spaces, spans, and other things that required the HTML editor to fix. When I went into the pretty HTML editor and searched for some text near the spot, it couldn't find it. I went back and forth between the views a few times and wondered if my script that cleans up the code had suddenly stopped working and started wiping out entire sections of content. Thankfully, I knew enough to use try the raw HTML editor and find and fix it (and my script was still sane).

JeffCampbell
Community Contributor
Author

@dlyons 

I'm not certain how we can say the issue is fixed, or even say that what @James is saying is a different issue. What he is describing happening to him right now is exactly what was in my original post...that it is not correctly reporting the correct number of search results in the Pretty HTML Editor. It only shows what it can see one the portion of the page that is visible at that time, plus a bit above and below. I just tested it again by loading up a page I have about sketching. There are 69 instances of the word "sketch" on the page, as seen in this search using the Raw HTML Editor:

Canvas Raw Editor.png

When I switch to the Pretty HTML Editor, it returns a result of zero:

Canvas Pretty Editor.png

Based on what you are saying, it should be scrolling to the results in the Pretty HTML Editor, even if it is reporting an incorrect count. On my end, it does not scroll to any of the instances. The way it is behaving, Canvas is acting as if the Pretty HTML Editor cannot see any of the results.

@Stef_retired I know this got archived, but both James and I are seeing the exact same issue is still in existing. I think it should be unarchived as the issue is not resolved.

Stef_retired
Instructure Alumni
Instructure Alumni

@JeffCampbell  Typically, when an idea conversation turns out to be a bug that we've acknowledged and are addressing, we archive it because bugs do not need to be evaluated or rated by the community at large, and we archived this one rather than marking it as completed for that reason. Never fear, it's being addressed.

erinhmcmillan
Instructure Alumni
Instructure Alumni

Please see Text search (CTRL-F) behaves incorrectly wh... - Instructure Community  regarding this issue.

Thanks,

Erin

Stef_retired
Instructure Alumni
Instructure Alumni

Please follow the known issue document for updates:  [OPEN] Text search (CTRL-F) behaves incorrectly wh...