Jellypotato

TwelveBaud

Continuing the discussion from This thread has likes enough to hold merry men!:

And that seems to indeed cause jellypotato.

Jellypotato

noun
A nonsense bug that neither users nor Discodevs can figure out. Currently used to refer to a bug where clicking a user's avatar causes scrolling of the page and/or hijacking of usercard content. It is posible this term might encompass other bugs, but such use has not yet been encountered in the wild.

Hijacking and you

Any subsequent usercards you view will have the content of jellypotato causing usercard. While highly entertaining it also causes huge amount of confusion to unsuspecting users.

Current known jellpotato carriers

@aliceif

@ChaosTheEternal

@tar

First occurence: A post in /t/1000

(Just for the sake of having a thread titled "jellypotato...")

The issue seems to involve the horrible bundle of mis-minification known as _vendor-a597...8ef3.js, and -- if we believe any part of the machinery involved -- is a problem originating inside ~~RequireJS or jQuery replaceText~~. It's difficult to debug in that environment ~~since there's no meaningful source mapping, no lines to set breakpoints on (only entire libraries, and only when they're first loaded), and~~ no easy way to know which part of a library is responsible for the failure. "Thankfully", Discourse includes its own error reporting, which gives us access to otherwise-unavailable information.

When you attempt to pop open a usercard, Discourse fetches a JSON describing the content on the card, including the raw and cooked of the user's bio as well as a specially bakéd version that only includes a few lines and strips most formatting. After substituting several elements into the usercard template, Discourse attempts to detect if the the provided bio is too long (exceeds the 60 vertical pixels allocated for that purpose), and runs a script that's supposed to automatically truncate it and add ellipses. For whatever reason, that script fails with a TypeError: h(...).get(...) is undefined, but at an impossible location: _vendor-a597...8ef3.js line 11 > eval:24:1582.

My understanding, such that it is, is that this is where the jellypotato behavior comes in: Discourse Logster client-side detects that a JS error occurred, and submits information on what happened and where to Discourse Logster server-side. As part of the data collection process, Logster &&'s the tab's location with itself, ~~and -- due to the weirdness of the location object -- inadvertently triggers the browser refreshing the page.~~ Logster finally submits the error. At that point, jQuery AJAX is configured to execute whatever JavaScript is returned, but instead only the barestring OK makes it back. The browser throws another JS error since this can't be executed, ~~and only Logster's lockout timer on reporting multiple errors prevents recursive death.~~

@sam: Server-side reporter.rb:28 and client-side logster.js.erb:26 ~~to fix jellypotato behavior~~. Still unsure what to do about the original auto-truncation error.

Also, who wants a headache?
http://what.thedailywtf.com/assets/vendor-a597363d662748bdf35504ae0a0e8ef3.js line 11 > eval:24:1853
f/<@/jquery.autoellipsis-1.0.10.min:24:1853
.each@/jquery.prod:3:2880
n.prototype.each@/jquery.prod:3:845
f@/jquery.autoellipsis-1.0.10.min:24:1586
a.fn.ellipsis/<@/jquery.autoellipsis-1.0.10.min:24:2238
.each@/jquery.prod:3:2880
n.prototype.each@/jquery.prod:3:845
a.fn.ellipsis@/jquery.autoellipsis-1.0.10.min:24:2206
__exports__.default<._parse<@/discourse/components/text-overflow:8:9
applyStr@/ember.prod:17574:1
sendEvent@/ember.prod:11979:11
exports.default<.trigger@/ember.prod:29055:7
superFunction@/ember.prod:13300:15
CoreView<.trigger@/ember.prod:38298:7
superWrapper@/ember.prod:17106:15
Renderer.default.prototype.didInsertElement@/ember.prod:36969:27
Renderer_renderTree@/ember.prod:8100:9
.rerender/<@/ember.prod:39334:9
Queue.prototype.invoke@/ember.prod:872:11
Queue.prototype.flush@/ember.prod:937:13
DeferredActionQueues.prototype.flush@/ember.prod:742:13
Backburner.prototype.end@/ember.prod:167:11
Backburner.prototype.run@/ember.prod:222:15
run@/ember.prod:15458:12
Discourse.Ajax<.ajax/performAjax/args.success@/discourse/mixins/ajax:66:9
n.Callbacks/j@/jquery.prod:3:26906
n.Callbacks/k.fireWith@/jquery.prod:3:27724
x@/jquery.prod:5:11063
.send/b/<@/jquery.prod:5:14577

Onyx

Damn it man, did you just kill it?

... I kinda liked having it around. As annoying as it is at times ...

TwelveBaud

By the way, for those who were curious, line 24 of RequireJS (which is line 11 in the vendor bundle) is finalizer(); in the code below:

  function tryFinally(tryable, finalizer) {
    try {
      return tryable();
    } finally {
      finalizer();
    }
  }

Nothing that's anywhere near column ~~1582~~1853 though.

loopback0

@Onyx said:

Damn it man, did you just kill it?

Only until the next regression.

ben_lubar

That's not what regression means around these parts.

sam

I think the fix here is to ship an excerpted / cleaned html chunk to client and then shorten it. The excerpting libraries client side seem to be falling over on lots of edge cases.

I will get the logster bug fixed ... sounds bad.

Can you repro the weird && behavior?

TwelveBaud

I was wrong about the && behavior; jellypotato seems to be triggering off something else instead (attempt to move to the user page due to user card failure, maybe?). I've done some more detailed investigation with a rested mind and a fresh pot of coffee, and struck through parts of the post above (and updated the stack trace, now with line breaks!).

I've determined that the line that's causing problems is this one:

jquery.autoellipsis/src/jquery.autoellipsis.js at master · pvdspek/jquery.autoellipsis

Auto-ellipsis plugin for jQuery. Contribute to pvdspek/jquery.autoellipsis development by creating an account on GitHub.

Apparently getLastTextNode is not returning a jQuery object under some circumstances. ¯\(ツ)/¯
I don't know whether it's the bundle-with-sourceID or the minification, but Firefox's debugger does not want to set breakpoints anywhere near that part of the code, even though it does break it out of the bundle and unminifies it for me.

You already ship a bio_excerpt in addition to a bio_raw and a bio_cooked, which has no block tags, so maybe use that instead?

sam

I think this fixes it ... try to see if you can break it on try

yeah bio_excerpt was good just needed a bit of tweaking to allow newlines.

May 20, 2015

FIX: clean html before sending it to jquery for collapsing · discourse/discourse@8013b6a

A platform for community discussion. Free, open, simple. - FIX: clean html before sending it to jquery for collapsing · discourse/discourse@8013b6a