Firefox: links issues

[jusuff]

Under Firefox I've found few issues whit links adding/editing/pasting.

1. Adding a link: while adding a link containing the ampersand character (&) - ampersand is "escaped" to "&" in very strange way.
For example:
"index.php?module=x&func=view&id=1"
will be converted to
"index.php?module=x&func=view&id=1"
(first amp is escaped once, second - twice, third - thrice, and so on...)

2. Editing: this issue was described at ticket 20. Solution given by jf.hovinne (select entire link to edit) wont work - if we select entire link we get in edit pop-up no data. In fact - we cannot edit links in Firefox, we have to create them from scratch.

3. Pasting relative links: when pasting to editor relative link, for example:
"<a href="/rel/example">Relative link</a>"
WYMeditor converts it to:
"<a href="../../../../../../../rel/example">Relative link</a>".
However this happens only when WYMeditor is running on server (tested on localhost). When WYMeditor is opened as local file the same link is converted to
"<a href="file:///rel/example">Relative link</a>"
(also not correct).

All issues observed using Firefox 2.0.0.5 on Windows and WYMeditor from SVN (rev 396)

[bermi]

1. Adding a link

Fixed on changeset [399]. Double entity escaping protection was not using a global regex so it only protected the first entity.

2. Editing

Confirmed, selecting the whole link simply doesn't work. And I can also confirm that on FF + Mac OS the dialog does not report back the value of the new link.

It seems that sStamp is not found on any href value in the editor.

jfh. When is sStamp supposed to be added to the link? I can only see the stamp being generated at the time the dialog is submitted.

I think I'm missing something here.

3. Pasting relative links

Confirmed on FF + Mac OS too. This happened to me when I had copied the relative link from another FF window that used the same path. We might need to investigate a tittle bit more about this situation.

[jf.hovinne]

2. Actually it works when you select the link by dragging the mouse from the first/last character to the last/first one.
Unfortunately, if you double-click inside/beside the link, FF will return selection = BODY.
Both scenarios work fine in MSIE.
I guess we need the SAPI to fix that issue.

FYI, sStamp has no effect here - it's only used to find the newly created/updated link and to set its title attribute.

3. That's another browser issue.
In MSIE, you can get the raw clipboard value and manipulate it (see this._doc.body.onpaste in jquery.wymeditor.explorer.js).
In Gecko browsers, you simply can't access the clipboard, so we should parse and clean the pasted data after it has been pasted.
IIRC, the browser needs full URIs, including the scheme, otherwise it makes them relative to the current page.

[jf.hovinne]

r410 partially fixes 2) for scenarios like <a><strong>#text</strong></a> in FF.

[mr_lundis]

Editing links should work better now, since r652. Although double-clicking the link still won't work in FF.

[mr_lundis]

The editing of links will be fixed with full implementation of the SAPI in 0.6.

I cannot verify the relative link issues in FF3.6 - maybe this isn't an issue anymore?