Opening emoji selector crashes browser

[flabdablet]

@anotherusername Surely it would save a shitload of round-trips, though? I shudder to think how a page that requires thousands of HTTP requests to render is going to work over, say, a satellite connection.

[anotherusername]

@flabdablet Typically, the really slow part is closing and re-opening the TCP / HTTP connection for each request; the TCP open/close handshakes require several round-trips each. That's what keep-alive was designed to avoid.

However, there's also HTTP pipelining which allows sending a whole series of requests without waiting for the responses, which the server queues and sends one right after another. So that's basically what you described.

pipelining of requests results in a dramatic improvement in the loading times of HTML pages, especially over high latency connections such as satellite Internet connections.

Whether pipelining is supported (or enabled by default) varies from browser to browser.

[bb36e]

@anotherusername the headers also add quite a bit of overhead - given that each request's header is somewhere around 0.63kB and there's 2600 requests, that's about 1.6MB of headers...

[anotherusername]

It's kind of tangential here, though. What takes so long here is the Javascript churning out the dialog, not loading the icons. If they're not cached, you can see them loading -- after the dialog's been rendered -- and it's pretty fast. If they are cached, you don't even see them loading; you just have to wait for the JS to create that popup, but the icons themselves load immediately.

[flabdablet]

@bb36e said in Opening emoji selector crashes browser:

about 1.6MB of headers

And over a typical 25d/1u Mb/s ADSL connection, that's 12 seconds right there even assuming 100% pipelining.

I don't think I've ever seen a browser configured to pipeline more than about 20 requests. Making thousands of HTTP requests for tiny little files, even given every mitigating optimization, is always going to be slower than grabbing them all as a single archive under any plausible conditions.

@anotherusername said in Opening emoji selector crashes browser:

What takes so long here is the Javascript churning out the dialog

Then that particular piece of Javascript is fucking horrible and well overdue for a rewrite.

Javascript can emulate an Apple II computer quite accurately at greater than real time speeds. It ought to be capable of decompressing and rendering a bunch of images in a dialog without breaking a sweat.

[ben_lubar]

Wait, does Firefox still not support HTTP2? Is it opening a thousand TCP connections or something?

[Lorne Kates]

@boomzilla said in Opening emoji selector crashes browser:

@ben_lubar said in Opening emoji selector crashes browser:

They managed to make a hamburger that is not only different things stacked vertically but also different things stacked horizontally. I'm not sure if that's even something that can be compared to a food anymore.

Casserole menu!

Shitburger menu.

[Lorne Kates]

@ben_lubar said in Opening emoji selector crashes browser:

Wait, does Firefox still not support HTTP2? Is it opening a thousand TCP connections or something?

http://http2-explained.haxx.se/content/en/part9.html

9. http2 in Firefox

Firefox has been tracking the drafts very closely and has provided http2 test implementations for many months. During the development of the http2 protocol, clients and servers have to agree on what draft version of the protocol they implement which makes it slightly annoying to run tests. Just be aware so that your client and server agree on what protocol draft they implement.
9.1. First, make sure it is enabled

In all Firefox versions since version 35, released January 13th 2015, http2 support is enabled by default.

Enter 'about:config' in the address bar and search for the option named “network.http.spdy.enabled.http2draft”. Make sure it is set to true. Firefox 36 added another config switch named “network.http.spdy.enabled.http2” which is set true by default. The latter one controls the “plain” http2 version while the first one enables and disables negotiation of http2-draft versions. Both are true by default since Firefox 36.
9.2. TLS-only

Remember that Firefox only implements http2 over TLS. You will only ever see http2 in action with Firefox when going to https:// sites that offer http2 support.

Relying on a half-implemented protocol that is not on by default in modern browsers and that is STILL IN DRAFTEdit: "The HTTP/2 specification was published as RFC 7540 in May 2015.[8]" does not count as a solution.

Especially not when the problem is "I shouldn't load 2000+ images when I'm only displaying 20 of them".

Edit relying on a protocol that is barely a year old still doesn't replace "don't load 2000 fucking images at once"

[flabdablet]

@ben_lubar said in Opening emoji selector crashes browser:

Is it opening a thousand TCP connections or something?

[anotherusername]

@flabdablet said in Opening emoji selector crashes browser:

Then that particular piece of Javascript is fucking horrible and well overdue for a rewrite.

Well, in my testing, injecting the string containing the entire outerHTML for that took about the same amount of time.

I'd think that using the proper DOM manipulation functions should probably be faster, though. For instance, removing the nodes from the document and putting them in a nodeList is virtually instant, and moving them from the nodeList back into the document is also virtually instant.

[Lorne Kates]

@anotherusername said in Opening emoji selector crashes browser:

@flabdablet said in Opening emoji selector crashes browser:

Then that particular piece of Javascript is fucking horrible and well overdue for a rewrite.

Well, in my testing, injecting the string containing the entire outerHTML for that took about the same amount of time.

I'd think that using the proper DOM manipulation functions should probably be faster, though. For instance, removing the nodes from the document and putting them in a nodeList is virtually instant, and moving them from the nodeList back into the document is also virtually instant.

Or when you popup the emoji selector, it just gets the HTML for the one page you're looking at. And when you click to the next page/tab, it posts back, and gets the less-than 1kb of data needed to render 20 image tags. And then the browser loads those 20 images.

Shockingly enough, that means you don't have to do any fancy data parsing and DOM manipulation.

You're getting in too deep here. Stop. Take a step back. Realize there's a simple solution that already exists. It's called a web browser. Use it.

Dumbass "why don't we fix broken design with brokener design" is the reason we have this web 3.0 bullshit.

[ben_lubar]

@Lorne-Kates said in Opening emoji selector crashes browser:

"I shouldn't load 2000+ images when I'm only displaying 20 of them".

I think there's a faulty assumption here, since there are 13 tabs, and one doesn't have any images on it and another has one image on it. So you have 11 tabs and somehow you're only displaying 20 of the 1999+ images on each one.

[Luhmann]

@boomzilla said in Opening emoji selector crashes browser:

Casserole menu!

Cassoulet Menu!

It's superior because it has a weener in it ...

[bb36e]

@Lorne-Kates I mean, people have been doing that for a while with $.ajax... Don't fix what ain't broken

[anotherusername]

@Lorne-Kates I said basically the same thing 3 days ago, minus the "hurr durr web 3.0 is bad" shtick. Are you saying that it would be better to use an iframe instead? popup window? what exactly?

[Lorne Kates]

@anotherusername said in Opening emoji selector crashes browser:

@Lorne-Kates I said basically the same thing 3 days ago, minus the "hurr durr web 3.0 is bad" shtick. Are you saying that it would be better to use an iframe instead? popup window? what exactly?

• Click on Emoji
• Opens the lightbox
• Makes a request to server. data: {tab:1,page:1}
• Server sends back the html for tab 1, page 1. Which is pseudoly: <div><img src='emoji1.png' /><img src='emoji2.jpg' />....<img src='emoji19' /></div>
• The "viewport" of the lightbox becomes that chunk of htm
• Browser fires off 20 image requests, assuming it is via $.ajax()
• User clicks a different tab or a different page.
• Browser makes a request to the server, data: {tab: x, page: y}
• Rinse and repeat

That's it. That's all there is. I could write it in one line of js and a handful of lines of code. There's no need to inject 2000+ img tags right away and have the browser request them, so in case MAYBE the user switches tabs or pages.

This is basic web 2.0.

[swayde]

@Lorne-Kates said in Opening emoji selector crashes browser:

That's it. That's all there is. I could write it in one line of js and a handful of lines of code. There's no need to inject 2000+ img tags right away and have the browser request them, so in case MAYBE the user switches tabs or pages.

This is basic web 2.0.

So get Off your fat ass and commit the fix. Show them how it's done, you superhuman you!

[anotherusername]

@Lorne-Kates said in Opening emoji selector crashes browser:

@anotherusername said in Opening emoji selector crashes browser:

@Lorne-Kates I said basically the same thing 3 days ago, minus the "hurr durr web 3.0 is bad" shtick. Are you saying that it would be better to use an iframe instead? popup window? what exactly?

• Click on Emoji
• Opens the lightbox
• Makes a request to server. data: {tab:1,page:1}
• Server sends back the html for tab 1, page 1. Which is pseudoly: <div><img src='emoji1.png' /><img src='emoji2.jpg' />....<img src='emoji19' /></div>
• The "viewport" of the lightbox becomes that chunk of htm

Why does it make any more sense to generate that on the server than on the client?

• User clicks a different tab or a different page.
• Browser makes a request to the server, data: {tab: x, page: y}

There's no need to inject 2000+ img tags right away and have the browser request them, so in case MAYBE the user switches tabs or pages.

Yeah, that's pretty much what I said.

[anotherusername]

@swayde said in Opening emoji selector crashes browser:

@Lorne-Kates said in Opening emoji selector crashes browser:

That's it. That's all there is. I could write it in one line of js and a handful of lines of code. There's no need to inject 2000+ img tags right away and have the browser request them, so in case MAYBE the user switches tabs or pages.

This is basic web 2.0.

So get Off your fat ass and commit the fix. Show them how it's done, you superhuman you!

To be fair, the code that seemed to be slow was some huge promise/deferred monstrosity. In the short time I spent trying to figure it out, I couldn't even figure out where the array of emoji was coming from, to try to implement my own code to see if I could make it more efficient.

[Lorne Kates]

@swayde said in Opening emoji selector crashes browser:

So get Off your fat ass and commit the fix. Show them how it's done, you superhuman you!

Surprisingly, I have better things to do than fix people's broken shit for free.

@anotherusername said in Opening emoji selector crashes browser:

Why does it make any more sense to generate that on the server than on the client?

You could cache the generation of the html chunks to improve performance. But that's a small reason.

The reason is because sending a JSON chunk PLUS the code to turn that JSON chunk into html requires:

• You're transforming data twice more than you have to (dataset -> encode JSON -> decode JSON -> html template)
• You're also writing the HTML template
• And making the client request the JS library to do the JSON->HTML conversion
• AND making the client actual do the JSON->HTML conversion
• And you run the risk of fucking up that JSON->HTML conversion, such as what NodeBB does by sending all the emoji and transforming it into 2000+ images
• Assuming of course your JS doesn't have bugs, cross-browser or cross-device compatibility problems (E_MOBILE_THATSDIFFERENT)

So you've added extra layers of complexity and introduced extra points of failure, for zero added benefit.

And yes, I do mean ZERO. Assuming a sane JSON load, you'd have each emoji represented as, I assume, this:

{src:"/emoji.svg"}

vs. sending the html equiv <img src="/emoji.svg"/>

For a line-for-line savings of 5 bytes! Probably less since I doubt the JSON is that sane.

[Lorne Kates]

@anotherusername said in Opening emoji selector crashes browser:

couldn't even figure out where the array of emoji was coming from

Okay, I'm not the only one. I just tried too, to see how insane the JSON actual was (see above post). And couldn't. It's that shitty.

[ben_lubar]

@Lorne-Kates The json is requested by this: https://github.com/NodeBB-Community/nodebb-plugin-emoji-extended/blob/9c17e9ac37185d6a1d62f8c2b3f0d8e70d77fb84/public/scripts/items.js

The request is satisfied by this function: https://github.com/NodeBB-Community/nodebb-plugin-emoji-extended/blob/9c17e9ac37185d6a1d62f8c2b3f0d8e70d77fb84/lib/socketRoutes.js#L24

The variable it passes is generated by this mess: https://github.com/NodeBB-Community/nodebb-plugin-emoji-extended/blob/86f6e6d5227526c5ae172db0d0b95145b1d8d874/lib/parser/main.js

Note that none of this code is part of NodeBB, and none of it was written by any of the 3 main NodeBB devs.

[ben_lubar]

Takes very long to load emojis · Issue #13 · NodeBB-Community/nodebb-plugin-emoji-extended

Hi, when clicking on the emoji icon in the composer it takes very long to load the actual icon sets. In firefox I get even a "script stop" message. Using FF 46.01 on arch linux NodeBB v1....

@Lorne-Kates you may want to weigh in there.

[Lorne Kates]

@ben_lubar said in Opening emoji selector crashes browser:

@Lorne-Kates you may want to weigh in there.

I may, but all my bug reports get "E_NOTFF22_CLOSED", so we'll see.

[ben_lubar]

@Lorne-Kates said in Opening emoji selector crashes browser:

@ben_lubar said in Opening emoji selector crashes browser:

@Lorne-Kates you may want to weigh in there.

I may, but all my bug reports get "E_NOTFF22_CLOSED", so we'll see.

So I was right?

[Lorne Kates]

@ben_lubar said in Opening emoji selector crashes browser:

So I was right?

noooooooooooooooooooo

Takes very long to load emojis · Issue #13 · NodeBB-Community/nodebb-plugin-emoji-extended

Hi, when clicking on the emoji icon in the composer it takes very long to load the actual icon sets. In firefox I get even a "script stop" message. Using FF 46.01 on arch linux NodeBB v1....

[Lorne Kates]

@Lorne-Kates said in Opening emoji selector crashes browser:

@ben_lubar said in Opening emoji selector crashes browser:

So I was right?

noooooooooooooooooooo

Takes very long to load emojis · Issue #13 · NodeBB-Community/nodebb-plugin-emoji-extended

Hi, when clicking on the emoji icon in the composer it takes very long to load the actual icon sets. In firefox I get even a "script stop" message. Using FF 46.01 on arch linux NodeBB v1....

good jorb dumbboxing the thread instead of the comment.

[Yamikuronue]

@anotherusername said in Opening emoji selector crashes browser:

Why does it make any more sense to generate that on the server than on the client?

Because the person who controls the server size cares very much about retaining members and therefore cares very much about performance, while the person who controls the client is often someone with less budget to spend and significantly less vested interest in the site?

I mean... duh?

[bb36e]

This post is deleted!

[anotherusername]

@Lorne-Kates if you actually look at the generated HTML, there's a metric shitton of extra stuff... I think it'd probably be less overhead to send the list, plus the JS to turn it into the HTML.

<div style="display: block;" class="bootbox modal fade emoji-extended-modal in" tabindex="-1" role="dialog">
  <div class="modal-dialog modal-lg">
    <div class="modal-content">
      <div class="modal-header">
        <button type="button" class="bootbox-close-button close" data-dismiss="modal" aria-hidden="true">×</button>
        <h4 class="modal-title">Available Emoticons</h4>
      </div>
      <div class="modal-body">
        <div class="bootbox-body">
          <div class="tabbable">
            <ul class="nav nav-tabs" role="tablist">
              <li class="active"><a href="#emoji-activity" data-toggle="tab" data-ajaxify="false">Activity</a></li>
              <li><a href="#emoji-extras" data-toggle="tab" data-ajaxify="false">extras</a></li>
              <li><a href="#emoji-flags" data-toggle="tab" data-ajaxify="false">Flags</a></li>
              <li><a href="#emoji-food" data-toggle="tab" data-ajaxify="false">food</a></li>
              <li><a href="#emoji-modifier" data-toggle="tab" data-ajaxify="false">Modifier</a></li>
              <li><a href="#emoji-nature" data-toggle="tab" data-ajaxify="false">Nature</a></li>
              <li><a href="#emoji-objects" data-toggle="tab" data-ajaxify="false">Objects</a></li>
              <li><a href="#emoji-people" data-toggle="tab" data-ajaxify="false">People</a></li>
              <li><a href="#emoji-regional" data-toggle="tab" data-ajaxify="false">regional</a></li>
              <li><a href="#emoji-symbols" data-toggle="tab" data-ajaxify="false">Symbols</a></li>
              <li><a href="#emoji-travel" data-toggle="tab" data-ajaxify="false">Travel</a></li>
              <li><a href="#emoji-others" data-toggle="tab" data-ajaxify="false">Others</a></li>
              <li><a href="#emoji-legal" data-toggle="tab">Legal Information</a></li>
            </ul>
            <div class="tab-content">
              <div id="emoji-activity" class="emoji-container row tab-pane fade active in">
                <a class="emoji-link col-xs-6 col-md-3" title="8ball"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/1f3b1.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="8ball"> :8ball:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="art"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/1f3a8.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="art"> :art:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="badminton"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/1f3f8.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="badminton"> :badminton:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="baseball"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/26be.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="baseball"> :baseball:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="basketball"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/1f3c0.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="basketball"> :basketball:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="basketball_player"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/26f9.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="basketball_player"> :basketball_player:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="basketball_player_tone1"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/26f9-1f3fb.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="basketball_player_tone1"> :basketball_player_tone1:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="basketball_player_tone2"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/26f9-1f3fc.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="basketball_player_tone2"> :basketball_player_tone2:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="basketball_player_tone3"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/26f9-1f3fd.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="basketball_player_tone3"> :basketball_player_tone3:</a>
                <a class="emoji-link col-xs-6 col-md-3" title="basketball_player_tone4"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/26f9-1f3fe.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="basketball_player_tone4"> :basketball_player_tone4:</a>
                /* snip 135 more emoji in this section */
              </div>
              /* snip 12 more sections, 2,462 lines */
              <div class="tab-pane fade" id="emoji-legal">
                <p>The images used belong to different image <em>sets</em>. Which set an image belongs to is stated within the <code>data-set-id</code> HTML attribute.</p>
                <div id="emoji-legal-tdwtf" class="emoji-legal-container panel panel-default">
                  <div class="panel-heading">Images of the set <em>tdwtf</em></div>
                  <div class="panel-body">
                    <h4>Attribution</h4>
                    <p class="legal-attribution well well-sm"><!--​ https://github.com/boomzillawtf/tdwtf/tree/master/emoji/tdwtf --></p>
                  </div>
                </div>
                <div id="emoji-legal-emoji-one" class="emoji-legal-container panel panel-default">
                  <div class="panel-heading">Images of the set <em>emoji-one</em></div>
                  <div class="panel-body">
                    <h4>Attribution</h4>
                    <p class="legal-attribution well well-sm">Emoji provided free by <a href="http://emojione.com/" target="_blank">Emoji One</a></p>
                    <h4>License</h4>
                    <p class="legal-license well well-sm">#### Emoji One Artwork

                    *  Applies to all PNG and SVG files as well as any adaptations made.
                    *  License: Creative Commons Attribution 4.0 International
                    *  Human Readable License: http://creativecommons.org/licenses/by/4.0/
                    *  Complete Legal Terms: http://creativecommons.org/licenses/by/4.0/legalcode


                    #### Emoji One Non-Artwork

                    *  Applies to the Javascript, JSON, PHP, CSS, HTML files, and everything else not covered under the artwork license above.
                    *  License: MIT
                    *  Complete Legal Terms: http://opensource.org/licenses/MIT
                    </p>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>
<div class="modal-backdrop fade in"></div>

(and that just has one of the 13 sections... I snipped the other 12)

(Which is what it should do, with placeholders that get filled only if and when the user actually clicks on that tab.)

(fake edit: well shit, that's way over the 32,767 character post limit. I'll snip out most of the emoji for that section. I'm just proving my point further, though, really...)

[flabdablet]

@anotherusername said in Opening emoji selector crashes browser:

there's a metric shitton of extra stuff

That stuff all looks like zlib compression would make short work of it, so assuming the HTML is being sent compressed it shouldn't actually matter.

[bb36e]

@Lorne-Kates it's okay though, it uses promises and that's async so there's no blocking

[anotherusername]

@flabdablet said in Opening emoji selector crashes browser:

@anotherusername said in Opening emoji selector crashes browser:

there's a metric shitton of extra stuff

That stuff all looks like zlib compression would make short work of it, so assuming the HTML is being sent compressed it shouldn't actually matter.

True... but... the fact that just shoving that giant glob of text into the innerHTML of an element takes about as long doesn't bode well for it working any better. It suggests to me that a big part of the bottleneck is converting all of that HTML into a DOM tree. And the code currently does a lot of $('html...'). I don't know for sure, but it seems like it might be faster if it relied more on document.createElement.

[Yamikuronue]

This is the part the server would be generating:

<a class="emoji-link col-xs-6 col-md-3" title="8ball"><img src="https://what.thedailywtf.com/plugins/nodebb-plugin-emoji-one/static/images/1f3b1.svg" class="not-responsive emoji emoji-presentation" data-set-id="emoji-one" data-emoji-id="8ball"> :8ball:</a>

Let's look at this for a second:

• Why does the link need a column descriptor? It contains only a fixed-size image and a single word. There's nothing to scale. Move that shit to the container, jesus.
• Why does the link containing only an image need a title attribute if the image has an alt tag? oh, because it doesn't, well done there.
• Why does the image need class not-responsive? If bootstrap doesn't do the right thing with a fixed-size image, fuck bootstrap.
• why do we need both set-id and emoji-id? Can't we fetch the damn emoji based on the title or alt, something the browser can already make use of?
• For that matter, it'd be prettier and cleaner to show only the images, and have it insert the emoji-code when you click on it. You can stuff that into the alt-text and/or title-text, so the browser can make use of it as well. The name is just as discoverable that way, since it shows up when you click it, and the emoji popup doesn't have to be as fucking huge when you click it.

[Arantor]

@Yamikuronue said in Opening emoji selector crashes browser:

ji-link col-xs-6 c

Why does the link containing only an image need a title attribute if the image has an alt tag?

Because alt tags don't make tooltips whereas title tags do.

The rest is just fuckass-retardary that makes web devs look like hacks.

[Yamikuronue]

@Arantor But why is it on the a at all?

[Arantor]

@Yamikuronue I just looked at the emoji picker for the first time in ages.

It has all the names on it. I don't remember it having all the names on it, I remember it being only the image, whereupon the tooltip angle made sense.

I didn't know from context whether or the text was being hidden (we do this a fair amount; textual link styled away to an image so that screen readers can still process while visual browsers get the pretty designer-made images) but now I look... this is just a crock full of shite.

[flabdablet]

@Arantor said in Opening emoji selector crashes browser:

this is just a crock full of shite

It is a pail of dung and none may abide the odor thereof.

[Arantor]

@flabdablet I have no (working) nose and I must post?

[Lorne Kates]

@anotherusername said in Opening emoji selector crashes browser:

there's a metric shitton of extra stuff

Some of that is part of the modal popup framework, which would already be downloaded.

Some of that would still be shared between JSON and HTML (title, for example).

Some of that has already been downloaded (like the ID of the tab), so we can factor that out.

The rest is a bunch of dumbshit cruft that is exactly the reason why forcing this to render server-side is a good idea, because all of a sudden the devs have to KNOW and CARE about what they're doing.

[flabdablet]

@Arantor It is a container of excrement and it is very strong, such that none may abide by it.

Filed under: how do you smell?

[Arantor]

@flabdablet I wouldst not know how I smell for I have no power to sense yonder aroma that may waft.

[flabdablet]

@Lorne-Kates said in Opening emoji selector crashes browser:

all of a sudden the devs have to KNOW and CARE about what they're doing

And the Assumptions were without form.
And the Plan was without substance.