Textareas somehow created by JavaScript code aren't handled

[martin.von.wittich]

Hi,

we use the ticket system Kayako v4 ( https://www.kayako.com/ ) in our company. TIRE works fine for the two text fields on the main ticket page (see kayako1.png), but when I click on "New Ticket", it'll display some kind of javascript popup (as far as I can tell, that is just a <div> that is either generated by JS code or at least made visible only then by JS code), and after I've clicked on "Next", it'll take me to the "New ticket" view - and there none of the input/textarea fields are recognized by TIRE (see kayako2.png). I tried to figure out how exactly Kayako generates this page so I could give you some hints how this could be reproduced, but unfortunately I was unsuccessful. There's also no demo site available

I assume that Kayako somehow generates the "New ticket" view on the fly with JavaScript code, and that TIRE only looks for text fields when the page is loaded.

[martin.von.wittich]

Second screenshot.

[Troik]

just to add to that, I already find TIRE very useful, thanks for the recent additions.
But talking about ticket systems, we use ITRS in our company and I have a similar problem, most fields are recognised, but sadly the most important one were you enter the text/mail you write, isn't saved.


If you want to test it yourself, the developer has a demo on their site.
https://www.otrs.com/otrs-demo-trial/#OTRS Online Demo

Scroll down to Service Agent and click on OTRS Free Demo there.
Then click on ticket in the menu bar at the top of the page and then "new email ticket".


That is the text area I wanted TIRE for in the first place, if that would work, that would make me so happy.

[cbaker_admin]

Thanks for the link. I will test it out this weekend (school is back in session where I work, so my development time is limited mostly to weekends).

[cbaker_admin]

Just an update to let you know I'm still working on it. It turns out to be a relatively complex problem. Your site uses iframes with injected content documents and I have to find a way to retrieve those DOM elements in a general way that will work with any page. It's tricky, but not impossible (I don't think ).

[Troik]

thank you for looking into that, hope it can be done, I mean, the site has to tell the browser somehow that it's a text input area, right?

[Troik]

I am of course not a developer, so I'm not sure if that is helpful, but what I see when I "inspect" the element, it's flagged as contenteditable="true".
According to , thats been around for a while. Sadly it doesn't tell me if this can be used for anything else than text, e.g. checkboxes and such. Otherwise, couldn't that be searched for?

As I said, I have no idea if that is helpful, but at least to my noobish mind, it would sound good if we could identify all elements that have this attribute set to true?

[cbaker_admin]

Yes, I am aware of the contenteditable attribute. In fact, there is quite a bit of code in TIRE that addresses contenteditable elements and TIRE does, in fact, handle those elements.

But the kayako system you are using seems to inject script into an iframe (the editor window) that I'm having a problem detecting. That window runs a rich-text editor for data input. The problem I'm having is that the iframe is loaded after the main page is loaded and is not firing a load event (that's the action that triggers TIRE to parse the element for input type fields).

I'm still working on the problem. Next I'll try having a key sequence (maybe CTRL-SHIFT-T) the the user can enter to force a reload of the TIRE parsing routines. That way you can have TIRE re-examine the page after the editor is loaded.

[cbaker_admin]

@martin.von.wittich

Please try the . I've been testing it with the page you mentioned and it seems to be working.