Classifier: Text Task gain too much height ("rows") when Firefox's text-only zoom is enabled

[shaunanoordin]

UI Bug

Originally reported in https://www.zooniverse.org/talk/17/2132332

Text Task's <textarea> dynamically calculates its "rows" attribute so that the height of the text box always matches the height of the text content. (i.e. users won't need to scroll up/down to see what they typed.) This works fine in most cases, UNLESS the browser has some sort of "Text-only zoom" feature enabled.

When this happens, the height of the text box will never match the height of the text content, usually meaning the text box has too much height (too many rows). i.e. if text-only zoom is set to 200%, the text box has approx. twice the height of the text content. (This also works the other way - text box is too small if text-only zoom is at 50%)

Example: in Firefox 92, a test project has text-only zoom at 200%. Despite typing only 2 characters, the textarea has 4 or 5 rows of height.

• Noted on Firefox 92, on commit 3bbf77
• Replicated on Ubuntu and macOS 94

Dev Notes

To replicate:

• create any Zooniverse Project with one Text Task.
• Open Firefox 92. In settings, set Default Zoom to 200% and enable "Zoom text only"
• Open the project in Firefox. You should see your Text Task.
  • Expected: Text Task's <textarea> should only have 1 row
  • Actual: textarea starts with 2-3 rows.
• Type in 2 characters (e.g. "eg")
  • Expected: textarea should STILL only have 1 row. The number of rows should correspond to the number of "lines of text".
  • Actual: textarea expands to 5-15 rows. Basically, a LOT of space for only 2 characters.

Note: the actual zoom value doesn't matter as much. What matters is that "text-only zoom" is enabled.

Analysis:

• The issue occurs specifically at this line of code let newRows = this.textInput.current ? Math.floor(this.textInput.current.scrollHeight / LINEHEIGHT) : oldRows;
• LINEHEIGHT assumes a hardcoded height of 22.5, which makes sense only if the text box and text content share the same zoom/scaling
• Long-term solution? Unknown. At the moment there's no standard API to detect if/when a user changes the zoom level of their browser, since zooming should only be a client-side decision. (Otherwise you'd have JavaScript trying to wrestle away control from the user settings which had wrestled control away from the JavaScript in the first place.)
  • Possible hack 1? Hack 2?
• Workaround? Disable "text-only zoom".

Status

Open issue. I'm currently marking this as low-priority, as the users who originally reported the problem are happy with a workaround.

Still, a proper fix (which doesn't rely on hacks) would be welcome, as I'm aware that there may be users out there who rely on text-only zooming.