CTRL+F Dynalist chrome, javascript keeps going back to start point of search

I changed the default CTRL+F on dynalist so it doesn’t use its intended function, and now I have chromes original CTRL+F function.

However, the problem I have at the moment, is this:

Basically, I find a designated location for my word, and I want to stop the CTRL+F search and end off there, but I end up going back to the very top of the page every time right where I started making searching for me kind of pointless with chromes ctrl+F

How can I fix this? Normally on a regular page like wikipedia, this behavior does not happen. See example on wikipedia’s page

there’s some form of javascript going on here with the ctrl+F key specifically on dynalist.io and I don’t know how to resolve it right now to get my original intended ctrl+F chrome search

this is what my settings look like right now


as of right now, basically, I have to rescroll back everytime I do a CTRL+F search when I click to edit that designated bulletpoint, and then after I do that, I exit out the search pressing the ESC key

1 Like

I have this issue as well. See also

strange i looked into that thread, I have this problem for both my windows 10 and windows 7 PC

I guess I will just have to identify the javascript responsible and then use NoScript / Umatrix for now to block it out

I will have to look at what the event handlerfor ctrl+F later and figure it out, unless, could Erica point it out to save the time and hassle? :slight_smile:


I figured out which part of the source javascript file, I think. My javascript knowledge is not that great, please clarify if this is correct:. I searched “ft.F”

ls.DOC_SEARCH=hs("doc-search",new _s([Pt.META_CTRL],ft.F),!0,!0),

also other keywords

  • “ft.F” (?button event handler? for “F” key)

  • “Scrolltop” - javascript function for scrolling to the top

  • “DOC_SEARCH” variable name defining methods of scrolling

  • “_scroll_page_up”

  • Variable “R” controls the keyboard input for “DOC_SEARCH” most likely when CTRL is pressed


  • Something with these variables here, that connects scrolltop javascript function and DOC_SEARCH, i haven’t found out the relationship yet

http://i.imgur.com/gMEMpus.png(not sure if variable R has anything to do with onpress event)

Tried using umatrix to disable javascript, but that disables everything useful too

I would have to run tamperscript to inject my own javascript to disable the onkey command ctrl+f, specific to dynalist or disable scrolltop or have some procedure to modify the javascript on my end everytime I load anything on dynalist’s domain

Unless there’s a bug fix for this coming out?

Sorry for the late reply here, this was just brought to my attention.

Nice detective work there, I really appreciate the effort! Unfortunately though, I believe the problem you are tracing is from a different part of the code.

I believe that this might be caused by the code we wrote for another “feature” if you want to call it that way. When you change focus from Dynalist to another application, then come back (for example, using Alt-Tab twice), Dynalist puts your cursor’s focus at the item you were at before Dynalist lost focus.

We had to do it that way because:

  • The browser won’t do it automatically
  • Many users switch between Dynalist and another app/page often to take notes, or copy items

Now, I believe when you use the browser’s (chrome) search, it makes the page believe that it has lost focus. This way, when you exit browser search, Dynalist recognize that as you coming back, thus re-focusing where it was.

The bad news is that we can’t distinguish between real focus lost and browser’s search focus lost.

But I have an idea: If you do happen to have scrolled when Dynalist was out of focus, we’ll treat it as a sign to not focus back to where you were. I believe this should solve your problem.

Let me know what you think about this and I’ll get it into Dynalist.


Okay this makes sense, I guess this is what all the javascript scroll functions in that 25,000 lines of code I was viewing at earlier? (which is powered by nodeJS on backend)

Would you happen to have more information on chromes “lost focus” ability? I would like to read up more on it

I think I’ve seen this issue elsewhere, when I had to do screencaps and page archiving

also I had to reread that a few times, but now it makes more sense

I’m still confused by what you mean here though. I tried ALT+TABing (you mentioned this earlier), isn’t this just changing the current window (I’m on windows 10, it has that apple-like feature where you can pick your windows)

Wouldn’t an easier suggestion just to be disable dynalist’s out of focus when the keys CTRL+F are pressed, with hotkey settings on the original CTRL+F for dynalist changed?

okay I reread it again, it took me awhile to understand it

Basically: When you refer to scroll you are referring to the javascript’s scroll function during chrome’s ctrl+F searches normally. Your suggestion is to disable it when dynalist was “out of focus”, which is what chrome does when it ctrl+F searches, so these 2 scrolling functions (chromes search scroll, dynalist’s “where my last position is cursor” scroll) don’t compete with each other.

But the functionality of dynalist’s “last position is cursor” is originally there still (something you guys implemented), which is something you had to have, otherwise when you revisited a page you had closed previously, it would just sit wherever you were, not at the top of the page

basically 2.0: When they do compete with each other, the following happens: ✪ ctrl+F chrome search ✪ Dynalist believes screen is minimized / your on a different window pane like thunderbird ✪ You enter in the items you want to chrome search ✪ You navigate to the chosen word ✪ Press ESC ✪ Dynalist believes you had just reopened the window / new tab, so it implements Javascript Scrolltop function ✪ because if it didn’t and you reopened a page, you might appear at the bottom as opposed to top of page

your suggestion is to implement somtehing to sense when dynalist is scrolling (javascript function events? from chrome search , onkeypress?) when dynalist thinks the page is closed, in order to disable javascript scrolltop function during ctrl+F searches

We used scrollTop somewhere else in the code, but in this case, we don’t manipulate scroll directly - Instead, we focus on the element, and the browser automatically scrolls to make the element visible.

That’s pretty accurate, minus the Dynalist trying to scroll part. Scroll happens because Dynalist focus back to the item you were on, and the browser scrolls there itself.

I think that’s correct.

We added a fix for this on the web version, did you notice any difference? @Vincent_Tang


I thought this might help with the problem I’ve had searching for terms in notes that extend in length beyond one screen, but there is still the same problem of jumping to the top once the text is clicked.

I didn’t think about this but it seems I have no more ctrl+F issues anymore :slight_smile:

1 Like

Yeah I don’t think that’s related to this issue, unfortunately.