search

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.
https://chrome.google.com/extensions/detail/ljobjlafonikaiipfkggjbhkghgicgoh
GNU General Public License v3.0
512 stars 91 forks source link

read-only textarea set to read/write later by JS not working #99

Open mbunkus opened 10 years ago

mbunkus commented 10 years ago

I'm using the extension (today's git) with OTRS. Some forms in OTRS are rendered in a two-step process: output a lot of HTML, all form fields marked as read-only initially. Then several fields are loaded via AJAX calls (it looks that way), and the read-only fields are switched to read/write mode.

Unfortunately these textareas are totally ignored by edit-with-emacs. I've verified that this is due initially due to the check in javascript/textarea.js:175. If I comment out that line then the extension works with those fields as well.

I haven't debugged further why the emacs-with-chrome doesn't detect this kind of page modification, though.

stsquad commented 10 years ago

Well the readOnly() test exists so text areas that can't be added don't get tagged. What should happen is when the DOM updates and a textarea is made writable it should trigger:

function handleUpdatedElements(summaries)

And that will tag the text area again at which point the readOnly() test will fail. Is there a public page that I can test this on? Otherwise you could try adding some console.log() statements to handleUpdatedElements() and see if they are triggered when the DOM changes occur.

mbunkus commented 10 years ago

Thanks for the fast reply. There is a public demo: Go to http://otrs-addons.otrs.com/otrs/index.pl?Action=Login&User=2ndlevel-E&Password=otrs123 . Click on any of the ticket entries listed below, e.g. »New tickets« section. In the new mask there should be a drop-down box marked »Reply«. Select any of the options with in that drop-down box and a popup should open. The textarea in this popup is what I'm talking about.

Unfortunately the demo is one minor revision ahead of the version I've experienced the issue on myself (3.2.x vs our 3.1.x), so I cannot guarantee that the problem still occurs there. If you cannot reproduce it I'll try to debug it further by digging into handleUpdateElements as you've suggested.