Giters

stsquad / emacs_chrome

A Chromium/Firefox "clone" of It's All Text for spawning an editor to edit text areas in browsers. Based on David Hilley's original Chromium extension.

Home Page:https://chrome.google.com/extensions/detail/ljobjlafonikaiipfkggjbhkghgicgoh

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Skipped textareas can remain skipped even after they have been revealed

phil-s opened this issue · comments

commented

Firefox: 89.0.2 (64-bit) on GNU/Linux
Edit With Emacs: Version 1.16 "Last Updated 15 January 2021"

With logging enabled I'm seeing the following in the console:

findTextAreas: running over 1 textareas.js:37:26
tagTextArea: skipping offscreen text area issue_description (0/95 x 0/-5) textareas.js:37:26
tagTextArea: skipping offscreen text area issue_notes (0/99 x 0/-5) textareas.js:37:26

I can reveal these hidden text areas by clicking a button (the application is a private instance of Redmine where clicking an "Edit" button exposes the edit form), but the extension doesn't pick up on this change, so the act of skipping them in the first place becomes counter-productive.

To make matters worse, the contextual menu for the textarea is being processed, so I can invoke the editor that way -- but it uses the text from some other textarea in some other browser window!

The official demo version of redmine looks different and does not exhibit this same behaviour, so I can't provide a link for reproducing this, but I can see that the "Edit" / "Cancel" buttons are using Javascript to update a div which is wrapping the edit form, setting display: block or display: none as appropriate.

If the extension isn't able to cope with that kind of change, I think it would be better to not skip textareas, and instead just assume that they may be visible at some point?