Ticket #69 (assigned defect)

Opened 1 year ago

Last modified 1 year ago

Firefox: links issues

Reported by: jusuff Assigned to: jf.hovinne (accepted)
Priority: major Milestone: 0.5
Component: Editor Version: trunk
Keywords: Cc: jusuff@op.pl

Description

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)

Change History

07/26/07 17:07:16 changed by bermi

  • owner changed from jf.hovinne to bermi.

07/27/07 03:12:31 changed by bermi

  • status changed from new to assigned.

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.

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.

07/27/07 03:22:02 changed by bermi

  • owner changed from bermi to jf.hovinne.
  • status changed from assigned to new.

07/27/07 14:01:37 changed by jf.hovinne

  • status changed from new to assigned.

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.

08/22/07 13:07:27 changed by jf.hovinne

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

09/06/07 12:55:07 changed by jf.hovinne

  • milestone changed from 0.4 to 0.5.