Steps to Reproduce the Bug

1.click E to open the backpack
2.input the item which you want to search in the search input line
3.click ctrl+A to select or press and hold the shift+left to select some words

Expected Behavior

if click ctrl+A, the all word will be selected
if hold the shift+left,the number of letters you click left will be selected

Actual Behavior

I can't use the normal shortcut keys to select all the words or some letters

Mod Pack URL (Optional)

No response

Mod Pack Version (Optional)

No response

Extra Notes (Optional)

minecraft version:1.18.2
forge version:40.1.68
jei version: 9.7.0.209 or 9.7.1.232
ftb-library version:1802.3.6-build.140
Architectury API version:4.7.78

latest.log

No response

Thanks for the report! Can you please report this to ftb-library and link back here?

ok,thank you. I have reported the issue to the ftb team.
the link is FTBTeam/FTB-Mods-Issues#403

Thanks for the report!
Can you please report this to ftb-library and link back here?

I just updated #2986 with the actual cause of the problem, but I'll paste here too, since this issue remains open:

This will be fixed in the next FTB Library release, but the problem is more subtle than a straightforward FTB Lib bug, so I'll comment here with the technical detail...

I originally thought this was FTB Lib somehow swallowing the Ctrl-A keypress, but not at all. The keypress actually gets through to JEI just fine. The actual problem is due to the exclusion area that FTB Lib reports to JEI (via getGuiExtraAreas())

The area reported by FTB Lib has a negative (X,Y) value - (-1, -1) to be precise (due to a bounding box calculation and expansion of that box by 2 pixels in each direction). JEI doesn't like negative coordinates, and silently clamps the -1 values to 0 in GuiScreenHelper#updateExclusionAreas(), the ImmutableRect2i constructor to be specific.

Problem with that is, on the next frame JEI compares that updated rectangle with the value that FTB Lib gives - and it's mismatched, every time. So JEI goes and calls updateScreen() on its two overlays, every time, and one of the results of that is that the filter textfield loses its selection.

(That was... interesting... to track down)

Couple of possible solutions:

• Throw an exception if the X/Y values are negative. Risky, since it could crash a lot of existing code.
• Just allow negative X/Y values in the exclusion areas. If they're only used to check for overlaps (which, looking at code, appears to be the case), this should be pretty safe?

This has been automatically marked as stale because it has not had recent activity, and will be closed if no further activity occurs. If this was overlooked, forgotten, or should remain open for any other reason, please reply here to call attention to it and remove the stale status. Thank you for your contributions.

This has been automatically closed because it has not had recent activity. Please feel free to update or reopen it.