[Greasemonkey] Textarea woes

[csaba2000]

As far as I can tell, it is impossible to determine the following things
about textareas via plain javascript.  Could you figure any of these out
from the GM framework?

1.  The focusOffset or caret position, if you will.  This is not the same as
textarea.selectionEnd because the selection in the textarea may have been
created by dragging the mouse left.  It also seems impossible to set a
"reverse selection" programatically.

2.  The column position/row position of the caret within the textarea (lets
assume that it's at textarea.selectionEnd).  This is not the same as
counting \n within textarea.value because of wrapping - I can figure out the
column/row within the text, but I want to know it within the textarea
element.

3.  The actual text as the user is viewing it in the textarea.  In other
words, I am looking to find (what should be) the text that would be
transmitted if textarea.wrap were set to hard and the containing form were
submitted.

By GM framework, I mean to suggest that it would be OK if I had to manually
add a function within the GM code itself.  I have done that in other
contexts.

Thanks,
Csaba Gabor from Vienna.

Below, to get the creative juices flowing, I detail several approaches that
did not work and why.  These are ideas that ought to work, but are buggy
(and have bugs logged on most of them).  .selectionStart is (currently)
constrained to be no greater than .selectionEnd.  Issuing a control down
arrow KeyDown event (to get the caret to the left of the textarea to measure
the column number) is received but not acted upon (supposedly fixed in
trunk, but I'm skeptical).  None of the values, textarea.textContent,
.toString(), .innerHTML, .value, .defaultValue return the text that
corresponds to what you visually see.  If I submit the textarea to an
about:blank iframe, then the iframe can take an onload event handler and
will respond (unlike standard GM, I might mention).  However, "security
considerations" prevent the calling document from getting to it (this may be
changed in the future, but probably not soon).  On the other hand, if I
submit the textarea form to the iframe (iframe submission avoids a hit to
the server), using the data protocol, I could react and get to that DOM, but
the data: protocol at http://www.w3.org/Submission/web-forms2/ is not yet
implemented (wherein the form data is encoded into the submitted data).  Oh,
and did I mention that textarea.wrap cannot be altered using javascript. 
Fortunately, I did discover a workaround for that by cloning the textarea.

So there is only one thing that sort of kind of falls into being able to do
any of these, and that is that I have altered my copy of GM to respond to
arbitrary about:blank pages (thanks GM), and with a little bit more
monkeying, I can receive a textarea form (after having simulated setting
.wrap to hard) and transmit the textarea representation back to the calling
page so in this way I could find out what the user is seeing (except that
unfortunately, FF does not correctly submit textareas with .wrap=hard (it
breaks the lines wrong - problem with the .cols setting)).

So my question, is can GM, or the innards of GM, come to my rescue?  The
most likely being that perhaps a GM innard issues keydown event will be more
favorably received?  Or perhaps GM innards can get ahold of the selection
representation/direction.  Or something?
--
View this message in context: http://www.nabble.com/Textarea-woes-t1396757.html#a3756452
Sent from the MozDev - greasemonkey forum at Nabble.com.