search

roygbyte / crossword.koplugin

Crosswords on your KOReader device
GNU Affero General Public License v3.0
12 stars 2 forks source link

Top row activate virtual keyboard #10

Open neilswann80 opened 3 months ago

neilswann80 commented 3 months ago

I've noticed a strange bug affecting the top row.

If you press the first square (1,1) it activates the first row of the virtual keyboard i.e. the left-cursor (previous clue) button.

If you press any other square on the first row it seems to activate the "current clue" section of the virtual keyboard thereby changing the solve direction.

If you press squares in the top-row whilst looking at the virtual keyboard you can see it's being triggered.

nathonius commented 3 weeks ago

I'm seeing the same thing. I'm guessing its something that's broken with recent koreader updates. I'm not familiar with the koreader source, but I'm going to take a crack at figuring out the issue here.

EDIT: After digging into it... I have no clue.

I think I can confirm it's not a simple off by one error though - it's not really the first row that has issues, as the problem area also seems to extend somewhat into the second row. This is easier to reproduce using the local emulator where you can precisely click.

roygbyte commented 2 weeks ago

@nathonius, thanks for the comment/reminder. This issue has plagued the plugin since as long as I can remember. So if it has something to do with a KOReader update, then that goes way back.

I poked around again with the behavior within the emulator. It appears that it's an area of the screen that produces this behavior, and not a range of cells. You can observe this by comparing the behavior between a regular crossword and a Sunday crossword. The Sunday crossword is more dense--more rows and columns. And the behavior extends into the fourth row (only by a bit! Some parts of the fourth row do not trigger the behavior). By comparison, in a regular crossword the behavior is triggered in the first two rows. Thus, I think it's a region of the screen, and not the cells.

What to do with this observation? I'm not sure yet!

nathonius commented 2 weeks ago

My instinct would be to compare the koreader navigation header tap area to the range that triggers this behavior. Nothing that I saw in the code building the layout looked suspect otherwise.

roygbyte commented 2 weeks ago

Another thought (maybe a memory, actually) would be to log key presses from softkeyboard.lua. If I do recall, I believe taps in the area of the screen affecting this erroneous behavior may be triggering a keyboard event.