Disable next/previous match buttons when no text is in Find box

[JasonWeill]

References

Fixes #15813.

Code changes

Disables the next and previous match buttons when there is no text in the Find box.

User-facing changes

When no text is in the Find box, the next and previous match buttons are disabled, do nothing when clicked, and appear with 60% opacity, the same level used for disabled commands in the command palette:

When there is text in the Find box, the next and previous match buttons are enabled and work the same way as before:

Backwards-incompatible changes

None.

[jupyterlab-probot]

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

[JasonWeill]

@krassowski With the most recent code pushed to this branch, the buttons now appear dimmed (less opacity) when the Find box is empty, but they still show a different background color on hover. I can pick this back up tomorrow.

[JasonWeill]

The CSS rules are now updated to suppress hover and active effects on disabled buttons.

[krassowski]

Looks good in general, some tiny suggestions to consider.

[krassowski]

When I hover over the debugger button when disabled it shows not allowed cursor. When I hover over the disable search buttons they show hand cursor. Should we align to the debugger button style?

Suggested change

	opacity: 0.6;
	opacity: 0.6;
	cursor: not-allowed;

[krassowski]

Also debugger button uses 0.4 opacity (I do not have a preference here).

[JasonWeill]

I don't see the pointer cursor on the prev/next buttons in Firefox ESR, and the cursor: not-allowed rule doesn't seem to change the cursor to the 🚫 cursor as your animation shows.

[krassowski]

Performance: having a generic element with three pseudo-elements on the right hand side of selector is not great. I don't feel like fiddling with it, but one way to make it work and eliminate performance impact would be making all the buttons within .jp-DocumentSearch-overlay use a common class name (in addition to the specific class names they already have). Another solution would be switching to jp-button element from ui-compontents which is only slightly better than button because if user has 1000s native buttons in their notebook our styles would not cause any performance penalty (of course until they start using jp-button).

[krassowski]

Tested locally works well:

Thank you @JasonWeill!