Jellypotato
-
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
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 insideRequireJS or jQuery replaceText. It's difficult to debug in that environmentsince there's no meaningful source mapping, no lines to set breakpoints on (only entire libraries, and only when they're first loaded), andno 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 theLogster finally submits the error. At that point, jQuery AJAX is configured to execute whatever JavaScript is returned, but instead only the barestringlocation
object -- inadvertently triggers the browser refreshing the page.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
-
Damn it man, did you just kill it?
... I kinda liked having it around. As annoying as it is at times ...
-
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
15821853 though.
-
-
That's not what regression means around these parts.
-
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?
-
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:
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 abio_raw
and abio_cooked
, which has no block tags, so maybe use that instead?
-
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.