Duplicate URLs have their textareas linked

[docwhat]

Christian,

I'm experiencing another issue with the current IAT,
but the software with which it is having the problem
(our Zimbra web-based mail user agent) was also recently
upgraded so the conditions are a bit muddled.

The short issue is that independent TEXTAREAs are associated
with the same edit file.

In Zimbra this has the (potentially really super nasty and
unfortunate) consequence that the content of mail addressed
to person 1 replaces the content of mail addressed to person 2
and is possibly therefore sent to the wrong person.

I cannot replicate this issue in our other major web-based
authoring software (MediaWiki) as each edited page there --
even replicated edited pages of the same name -- appear to
get uniquely identified edit files.

I'm wondering how you define the name of the edit file and
if the new version of Zimbra is somehow creating generic
edit popups that cause IAT to create the same filename.

I'm aware of this and so I'm trying to limit email authoring
to one at a time, but this seems potentially quite nasty.

~drm

[docwhat]

Hi!

The filename is generated as a hash:

• a secret key
• the canonical URL (including get arguments, port number, etc.)
• the id of the textarea (one is autogenerated if it doesn't exist)

Normally, this lets you revisit a page and have the same filename for a textarea. Useful for editing.

However, if you try to open two pages with the same URL then the textareas become associated. You can reproduce this in mediawiki by editing the same page twice and trying to edit them at the same time. It's less of an issue, since it's the same wiki content after all.

But with email you might want to open a new email window multiple times but have different content, as you do.

Alas, I can't think of anything better than suggesting "don't do that".... which is a sucky answer, I know.

Hmm....okay, well thinking about it I suppose I could add a 'right click' option to use a random filename instead...but you won't be able to 'right click' and select 'Edit using previous .txt content...' when you do that....

I've added #16 to track this idea. I'm not sure I want to do it.

[AnneBennett]

This filename collision is a problem for me too; I cannot simultaneously edit two Wiki pages or one will stomp the other.

If adding a right click option to use a random filename only sometimes is more complicated than you want to deal with, perhaps a preference setting so I can turn on the use of random filenames all the time?

I love ItsAllText - I don't think I could do my job without it and stay sane, due to the number of web forms I need to deal with (Wiki, ticket system, etc). But this issue with the Wiki filename collisions rather slows me down!

Thanks for making such a useful add-on.

Anne.

[docwhat]

Anne: is the wiki public or is the kind of wiki open source?

[AnneBennett]

It's implemented with DokuWiki.

Anne.

[amc1804]

This has been biting me too, sometimes because I have two windows open
to the same URL, and sometimes because textareas on the same page have
the same id (which violates the HTML spec, I know, but it happens in
practice).

I never expect two textareas to be linked, and it always causes trouble
when it happens, so I would love to use random filenames, rather than
hashes, for all textareas. In those rare cases where I want to retrieve
the old text when re-visiting a page, I'll manually dig it out of the
cache directory.

Please consider relabeling this from a feature-request to a bug. I
think editing a textarea in one browser window and having it appear in
another browser window must be astonishing and undesired behavior to
almost everyone.

P.S. In general I love ItsAllText and can't imagine living without it.
Thanks for maintaining it!

[docwhat]

The code tries its best, but there isn't much I can do. I use an app that does this and I just have to have one open at a time.

Semantically, IAT must know what each text area is for. When two thing say they're the same IAT has to believe them.

The only other mechanism I could think of would be slow and just as error prone (the app I mentioned wouldn't be fixed by this) which would be to use something like an XPath with the form name and text area name. But lots of apps break this.

[AnneBennett]

I never expect two textareas to be linked, and it always causes trouble
when it happens, so I would love to use random filenames, rather than
hashes, for all textareas.

In the meantime, perhaps this can help. Here's my configuration:

Configuration of editor: /path/to/itsalltext-edit

-------------- itsalltext-edit --------------------------------
#!/bin/sh

@(#)itsalltext-edit 2005-09-27 Anne Bennett

For some reason, vim doesn't start up correctly in xterm (blank

xterm, no idea what's running in it if anything!) when an argument

is given to vim that contains whitespace. There seems to be no way

to correctly escape that whitespace. Anyway, this little script

fires up the right thing.

VIMINIT="so ~vin-anne/.vim/vimrc"; export VIMINIT

/usr/bin/xterm -e /usr/bin/vim '+set syntax=mail' "$@"

Keep a copy in case this is a situation where ItsAlltext generates

duplicate filenames for different pages, e.g. editing Wiki pages.

This should help me recover from disasters:

newname=echo "$@" | sed s'%/\([^/]*\)$%/copy.\1%'.date '+%Y%m%d.%H%M%S'.$$
cp -p "$@" $newname

Note the prepended string; it seems that IAT deletes all files

matching the start of ist generated name when it starts a new

session involving that filename!

wait
echo 1>&2 date ItsAllText exiting for "$@" with copy to $newname
exit 0

---

Anne.

Ms. Anne Bennett, as a private citizen: [email protected]
Also reachable more officially at work: [email protected]

[xOneca]

Maybe a tab-id or something like that can be used...

[docwhat]

But then it wouldn't work if you closed the tab and went back to the page and tried to reopen a text area..

[xOneca]

There would be more than one file with the same base, so wouldn't work as expected, I see...