Fix search coming back in notebook and editor

[krassowski]

References

Builds on the test proposed in #15259 (thanks @parmentelat)
Fixes #14871

Code changes

Track the search on/off state and only announce state changes/act on them if the search is on.

User-facing changes

Search does not come back in notebook and file editor

Backwards-incompatible changes

None

[jupyterlab-probot]

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

[parmentelat]

I just gave this a manual test
as binder was taking 10 minutes+, I went for a local install and did this

• went to commit 17b52c5
• jlpm install
• jlpm build
  with that in place I kicked a new jupyter lab

however I could not see any improvement, the searched terms keeps on being highlighted even when the search dialog is closed

so I take it the way I am trying to test is not right, is it ?

[krassowski]

jupyter lab --dev-mode (do you see the orange dev mode indicator at the top)?

If you still see it in the dev mode, can you record a screencast?

[parmentelat]

stupid me, I am more into developing extensions these days and I forgot about the --dev-mode (mental slap on the forehead ;)

all seems to be in order now; I'll try to give it a more thorough shot later on then :)

[parmentelat]

just to confirm, I have been able to test this manually with larger notebooks and so far I have not seen the search dialog reappearing unintentionally, so it's all good as far as I am concerned; at the very least it is way better than before :)

thanks a lot @krassowski for fixing this, it is a huge burden off heavy users who use Search all the time

ps1. I tried to analyse the outcome of CI that has many failures, it does not seem to relate to these changes but I could not say for sure

ps2. just as a comment, not quite related to the topic at hand, but
I think I remember having seen issues where people were not at ease with the search feature switching cells in edit mode
I think I understand the need to do that in cases where the search pattern would be present in the cell source but not in the rendered version; however in the vast majority of cases, it's not the case, so after all these manual tests, it's my feeling that this issue is maybe next thing that could be improved :)

[krassowski]

ps1. I tried to analyse the outcome of CI that has many failures, it does not seem to relate to these changes but I could not say for sure

No worries, I will take care of these. Briefly there are two issues: (a) we need to update snapshots as new PRs were merged since and the UI looks slightly different (b) parallel execution of tests on CI is breaking some test cases which is being worked on elsewhere.

I think I remember having seen issues where people were not at ease with the search feature switching cells in edit mode
I think I understand the need to do that in cases where the search pattern would be present in the cell source but not in the rendered version; however in the vast majority of cases, it's not the case, so after all these manual tests, it's my feeling that this issue is maybe next thing that could be improved :)

I agree from the UX point of view. Having it not touch render state and showing a tooltip "3 more matches in source code" could be a good solution IMO. If you cannot find an issue about this, please create a new one.

[krassowski]

bot please update galata snapshots again

[github-actions]

Galata snapshots updated.

[parmentelat]

@krassowski
thanks for youor invitation to review this PR; I can't say that I feel exactly relevant, but FWIW I do not see anything sticking out in the code changes

in any case I'd like to thank you a million times again for taking care of this nagging issue, I am eager to see this released so I can stop writing junk in the search dialog only to keep the issue from happening ;-)

[fcollonval]

Thanks a lot at @krassowski

[krassowski]

@meeseeksdev please backport to 4.0.x

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout 4.0.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 746ce2d75652a207fa1cdac07dd05854ac15eafb

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #15443: Fix search coming back in notebook and editor'

4. Push to a named branch:

git push YOURFORK 4.0.x:auto-backport-of-pr-15443-on-4.0.x

5. Create a PR against branch 4.0.x, I would have named this PR:

"Backport PR #15443 on branch 4.0.x (Fix search coming back in notebook and editor)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.