11

I've noticed over the past week or two (or three?) that Stack Exchange URLs in posts don't have their anchor text automatically converted to the title of the linked post during the edit and preview page anymore. For example, this,

  • https://meta.stackexchange.com/questions/108134/what-limitations-does-converting-question-links-to-links-with-titles-have

isn't automatically converted into this,

Here's a screenshot:

Screenshot

However, on post submission, the anchor text seems to still be converted automatically.

What's affected?

I've confirmed that this is the case for both questions and answers on multiple exchanges, including Stack Overflow, Meta Stack Overflow, Super User, as well as Meta Stack Exchange.

Shadow Wizard also confirms that I'm not (that) crazy,

@Cupcake you're right, you found a bug, links are not parsed anymore as they used to.

Is this a feature or a bug?

I thought maybe that, instead of being a bug, a new change might have been intentionally deployed recently to remove the automatic conversion, perhaps for performance reasons. However, searching recent MSE posts doesn't turn up anything about such a change, as far as I can tell.

Improve this question
2
  • 2
    It's a bug, the API is angry at the name of the JSONP callback used by the previewer: {"error_id":400,"error_message":"jsonp callback in either jsonp or callback was malformed or malicious","error_name":"bad_parameter"}
    – Tim Stone
    Commented Jul 10, 2014 at 10:58
  • The Attack of the Preview, @Tim?
    – Shadow Wizard
    Commented Jul 10, 2014 at 12:57

1 Answer 1

Reset to default
8

Fixed in the next build. We recently* tightened up restrictions on the API's JSONP callback parameter (mostly in response to this). Unfortunately we broke ourselves with that, because when retrieving the question title to show it in the preview we used a callback of the form apiCallbacks["meta.stackexchange.com"], which the new restrictions don't allow anymore. From the next build on, we'll use apiCallbacks.meta$stackexchange$com instead, which is still legal.

* This was not even two days ago, so either your "week or two" is your recollection messing with you, or something else is going on – but after this fix it does seem back to working, so I'm inclined to pick the former.

Improve this answer
4
  • 1
    You should totally drop that perfectly fine, working implementation and use CORS instead. Nobody cares about IE < 8 users/the handful of Opera users who still use the not-so-old version before support was added, and it's good to live dangerously. ;)
    – Tim Stone
    Commented Jul 10, 2014 at 14:37
  • @TimStone is that the typical "use jQuery" response of the cross-domain communication world?
    – user163250
    Commented Jul 10, 2014 at 17:07
  • @Cupcake Indeed
    – Tim Stone
    Commented Jul 10, 2014 at 17:07
  • Looks like it has returned
    – Shadow Wizard
    Commented Dec 1, 2014 at 12:00

You must log in to answer this question.