Make WordPress Core

Opened 4 years ago

Closed 22 months ago

Last modified 22 months ago

#11194 closed defect (bug) (invalid)

Visual Editor Creates Blank (Orphaned) Anchor Tags

Reported by: miqrogroove Owned by: azaozz
Milestone: Priority: normal
Severity: normal Version: 2.8.4
Component: TinyMCE Keywords: 2nd-opinion
Focuses: Cc:


Steps to reproduce:

  1. Insert image into new post.
  1. Place cursor at the left side of image.
  1. Press the delete key.
  1. Switch to HTML view.

Expected results: Blank post. :)

Actual results: Empty anchor tags, and sometimes paragraphs too.

Workaround: Various combinations of Delete and Backspace key strokes can get rid of the anchor, but it is somewhat unpredictable.

Change History (17)

comment:1 azaozz4 years ago

  • Milestone 2.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed

This is a browser bug. In FF you can't place the cursor before the image at all, in IE the delete key may behave unexpectedly (backspace works well), in Safari all seem to work properly.

There are many other oddities when the browsers are in contentEditable mode. Best would be to report these problems to the browser vendors.

For deleting images you can use the Delete button that shows when clicking on the image.

comment:2 miqrogroove4 years ago

  • Keywords 2nd-opinion added
  • Milestone set to 2.9
  • Resolution invalid deleted
  • Status changed from closed to reopened

Please reconsider the SEO consequences of having invisible links in blog posts. I can't believe there was a consensus about blaming the browsers.

comment:3 azaozz4 years ago

The delete button does not work as expected in Internet Explorer and Firefox. It works as expected in Safari and Chrome. There is no reliable way for TinyMCE or WordPress to fix these browser bugs, so I think they should be reported to the browser vendors and this ticked closed.

comment:4 miqrogroove4 years ago

What I'm getting at is if the browser is known to supply garbage, WordPress should filter it. <a href="google"></a> is easy to find and delete, is it not? Why be resigned to a garbage-in-garbage-out system?

comment:5 markjaquith4 years ago

  • Milestone changed from 2.9 to Future Release

Can anyone think of a valid case for an ID-less empty anchor?

comment:6 miqrogroove4 years ago


Google considers links "hidden in a small character" as deceptive and "intended to be crawled by Googlebot". They do not get specific about links that have no characters.

comment:7 nacin4 years ago

Replying to markjaquith:

Can anyone think of a valid case for an ID-less empty anchor?

And name-less. That said, such an anchor could be given size, shape and position via CSS. I'm not sure I'd consider that valid, though.

comment:8 Denis-de-Bernardy4 years ago

I think the keyword in google's FAQ item is this:

If your site is perceived to contain hidden text and links that are deceptive in intent, your site may be removed from the Google index, and will not appear in search results pages.

I honestly doubt that Google takes empty anchor tags into account. It basically treats the anchor's text as a tag. If there no tag, the link would presumably be ignored.

That said, it don't cost much to filter empty tags out on the content_save_pre hook using some regex foo. We just need to make sure that we're not stripping out stuff that contains a name or ID attribute.

comment:9 hakre4 years ago

Ahh, not another filter running on the_content. WYSIWYG is defective by design so I would not wonder about some empty tags within the code. If someone is bothering, should get a tidy plugin or so. I find it very hard to properly take care of the broken output when we now the editor / concept is broken.

comment:10 hakre4 years ago

I suggest to close as invalid or wontfix.

comment:11 follow-up: hakre4 years ago

miqrogroove any objections closing this as wontfix? or any suggestion on how to actually fix that?

comment:12 hakre4 years ago

It might make sense to test the behaviour against the default tinymce implementation and report bugs upstream.

comment:13 in reply to: ↑ 11 miqrogroove4 years ago

Replying to hakre:

miqrogroove any objections closing this as wontfix? or any suggestion on how to actually fix that?

hakre I don't file bug reports just for the thrill of seeing them rejected. As I pointed out above, filtering empty elements should be an easy accomplishment. I'd patch it myself, but I have close to zero experience in the post editing area of this code base.

comment:14 Denis-de-Bernardy4 years ago

@miqrogroove: note that you can strip those with a plugin in the meanwhile. the filter is content_save_pre, or something like that.

comment:15 miqrogroove3 years ago

This might be a different symptom of the same bug. Webmaster Tools just flagged this bit of garbage in the middle of a post:

<a rel="attachment wp-att-7429" href="http://domain.was.here/?attachment_id=7429"></a>

Not really sure how to reproduce that behavior, but it happened.

comment:16 azaozz22 months ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Cannot reproduce this in FF or IE9 any more, appears fixed in the browsers.

comment:17 helenyhou22 months ago

  • Keywords needs-patch removed
  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.