Ticket #69 (new defect)

Opened 5 years ago

Last modified 2 years ago

Firefox: links issues

Reported by: jusuff Owned by: mr_lundis
Priority: minor Milestone: 2.0
Component: editor Version: trunk
Keywords: Cc: 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:
will be converted to
(first amp is escaped once, second - twice, third - thrice, and so on...)

  1. 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.
  1. 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 on Windows and WYMeditor from SVN (rev 396)

Change History

comment:1 Changed 5 years ago by bermi

  • Owner changed from jf.hovinne to bermi

comment:2 Changed 5 years ago 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.

comment:3 Changed 5 years ago by bermi

  • Owner changed from bermi to jf.hovinne
  • Status changed from assigned to new

comment:4 Changed 5 years ago by jf.hovinne

  • Status changed from new to assigned
  1. 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.

  1. 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.

comment:5 Changed 5 years ago by jf.hovinne

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

comment:6 Changed 5 years ago by jf.hovinne

  • Milestone changed from 0.4 to 0.5

comment:7 Changed 2 years ago by mr_lundis

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

comment:8 Changed 2 years ago by mr_lundis

  • Owner changed from jf.hovinne to mr_lundis
  • Priority changed from major to minor
  • Status changed from assigned to new
  • Milestone changed from 0.5 to 0.6

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?

Note: See TracTickets for help on using tickets.