Describe the bug HTML is incorrectly stripped from runkit code blocks.

To Reproduce

1. Click WRITE A POST.
2. Paste into body:

{% runkit %}
const { ValueViewerSymbol } = require("@runkit/value-viewer");

const myCustomObject = {
    [ValueViewerSymbol]: {
        title: "My First Viewer",
        HTML: "<marquee>🍔Hello, World!🍔</marquee>"
    }
};
{% endrunkit %} 

3. Click SAVE POST
4. See code in runkit (incorrectly) translated into:

const { ValueViewerSymbol } = require("@runkit/value-viewer");

const myCustomObject = {
    [ValueViewerSymbol]: {
        title: "My First Viewer",
        HTML: "🍔Hello, World!🍔"
    }
};

Expected behavior Code was expected to keep <marquee> tags.

Additional Info I can trick the parser by encoding my HTML.

This works:

{% runkit %}
const { ValueViewerSymbol } = require("@runkit/value-viewer");
const atob = require('atob-lite')

const myCustomObject = {
    [ValueViewerSymbol]: {
        title: "My First Viewer",
        HTML: atob('PG1hcnF1ZWU+SGVsbG8sIFdvcmxkITwvbWFycXVlZT4=')
    }
};
{% endrunkit %}

Strangely enough, this does not work:

{% runkit %}
const { ValueViewerSymbol } = require("@runkit/value-viewer");

const myCustomObject = {
    [ValueViewerSymbol]: {
        title: "My First Viewer",
        HTML: ["<", "m", "a", "r", "q", "u", "e", "e", ">", "🍔", "H", "e", "l", "l", "o", ",", " ", "W", "o", "r", "l", "d", "!", "🍔", "<", "/", "m", "a", "r", "q", "u", "e", "e", ">"].join('')
    }
};
{% endrunkit %}

as it (incorrectly) results in this:

const { ValueViewerSymbol } = require("@runkit/value-viewer");

const myCustomObject = {
    [ValueViewerSymbol]: {
        title: "My First Viewer",
        HTML: ["", "🍔", "H", "e", "l", "l", "o", ",", " ", "W", "o", "r", "l", "d", "!", "🍔", ""].join('')
    }
};

Describe the bug Code blocks sometimes get breaks <br> added between each line. You can see it in the one codeblock on A month of Flutter: a look back. It appears to be related to having headers following the code blocks.

To Reproduce

Go to create a new post enter the following markdown and hit "preview".

~~~
function hello() {
  console.log('hello');
}
~~~

~~~
function goodbye() {
  console.log('goodbye');
}
~~~

# header

Expected behavior

The code blocks should not have any blank lines between each line of code.

Screenshots

Correct display when # header is not included:

Incorrect display when # header is included:

Desktop (please complete the following information):

• OS: Ubuntu 18.10
• Browsers:
  • Chrome 72.0.3626.28
  • Firefox 64.0

Additional context

The broken display only appears to happen when a header follows the code blocks. If I move it between or before the code blocks the breaks don't happen. I'm using v2 of the editor and have not tested with v1.

Describe the bug

The modal triggered by the three dots on the left of an article appears stuck under the navbar of the website, it is not readable entirely.

To Reproduce

After submitting an article but before publishing. Click on the three dots on the top left of the article. The modal will show up but a part of it is hidden behind the navbar

Expected behavior

The modal should appear entirely to see all the links. It can appear under the navbar, or on top of it.

Screenshots

Desktop (please complete the following information):

• OS, version: MacOS Catalina 10.15.7
• Browser, version: Chrome Version 88.0.4324.192 (Official Build) (x86_64)

Additional context button id="article-show-more-button"

Describe the bug

Each tag has an associated taggings_count which contains the number of items they are associated with (in our case either articles or listings).

The problem lies in the fact that some of these counts are incorrect in the DB.

I found this out by playing with the Tags API which returns tags sorted by taggings_count in descending order

For example:

1. archlinux according to the API - https://dev.to/api/tags - is the third most used tag but it's very unlikely that is true. Its tag page - https://dev.to/t/archlinux - lists 50 articles and even taking into account all listings it might have been used in, it doesn't add up
2. https://dev.to/api/tags?per_page=15 shows that devops is more popular than showdev but devops page contains 2917 articles, showdev page contains 3110. Again, I don't think there are enough listings tagged with devops to account for the difference

Thus, the bug.

This counter is managed by automatically by the acts-as-taggable-on gem.

Expected behavior

I'd expect the counter to reflect the correct number of items that have been tagged with it.

I see two possible explanations:

1. there's an error in our setup, in respect to the usage guide
2. it has something to do with tag aliasing (?)
3. there's a bug in the gem itself. I found a few issue tickets that might point us in this direction:

• https://github.com/mbleigh/acts-as-taggable-on/issues/929
• https://github.com/mbleigh/acts-as-taggable-on/issues/947

Describe the bug

Date tag on a comment is "Apr 27", but on hover the text is "Tuesday, 28 April 2020, 00:01:19".

In HTML, datetime content is 2020-04-27T22:01:19Z 🤔

To Reproduce

Hover date of this comment.

Expected behavior

Date on tag & on hover should be the same.

Screenshots

Desktop (please complete the following information):

• OS: Xubuntu
• Browser: Firefox
• Version: 75.0

Describe the bug When someone follows me, I get a notification with a "Follow back" button in it. But in some cases, the button has no text in it. As a consequence, it's not clear what the button does.

To Reproduce

1. Go to 'Notifications'
2. Find a "$USER followed you" notification
3. If the "FOLLOW BACK" text in the button in visible, refresh and check.

Note: I realise these aren't ideal steps to reproduce the issue but unfortunately that's all I have. I'm not sure about the exact cases for which the text is visible and for which the text is not. But I'll be glad to provide information, if needed.

Expected behavior The "FOLLOW BACK" text should always be visible in the button. For me, it's visible only at random times. The probability of the button having no text is higher.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Browser: Firefox/Chrome
• Version: 73.0.1/80.0.3987

Currently we user surrogate keys to determine when certain endpoints should have their caches cleared, such as an article API endpoint like this...

set_surrogate_key_header Article.table_key, @articles.map(&:record_key)

And then we call article.purge which magically makes any endpoint with that article's record_key have its edge cache expire.

More on surrogate keys...

https://docs.fastly.com/en/guides/getting-started-with-surrogate-keys

The issue with the above logic is that a new article which should become part of that endpoint will not flush its cache if created. So it will not show up on that endpoint until another article which fits within the above @articles is purged. This makes it kind of random to find out when it will be included.

article.purge is a magic method to create a purge ping which uses the appropriate surrogate header.

A solution for this could be a surrogate key like this...

set_surrogate_key_header Article.table_key, "tag-index-endpoint-#{tag}", @articles.map(&:record_key)

and then we make a specific purge call when a new article should purge it like purge("tag-index-endpoint-#{tag}" when an article is created.

Our current situation isn't causing any radically wrong behavior and the "random" purging is working okay but we should look into this as we go about bigger changes here.

Describe the bug

Followed a link from an email, attempted to respond to a comment, received error There was an error in your markdown: undefined method id' for nil:NilClass`, comment not posted.

To Reproduce

Follow link from an email, attempt to respond to a comment.

Expected behavior

Comment is posted.

Screenshots

Desktop (please complete the following information):

• OS: MacOS 10.15.3
• Browser: Chrome 80.0.3987.87

Describe the bug

First line in the block of text cannot be indented.

To Reproduce

1. Create a new post
2. Add following content, make sure all lines are indented.

{% runkit %}
    console.log('BAD CODE')
    console.log('OK CODE')

    // BAD COMMENT
    // OK COMMENT
{% endrunkit %}

3. Save the post

Expected behavior

All lines in RunKit embed should be indented.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10 Pro
• Browser: Opera
• Version: 65

Additional context

https://dev.to/tomaszrydzewski/runkit-indentation-2n9c-temp-slug-526549?preview=b14fe31c6205719176ea1eb56003f5a280d576a6c6e235a8587e6669eef1c45774687968a6bb6b677f09c7fc6a84289a59ceeb548b7d896fe1e94793

Describe the bug After following the installation with docker guide and accessing the locally hosted application, users' profile photos weren't showing up.

web_1        | Cannot render console from 172.20.0.1! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255
web_1        | GET /uploads/user/profile_image/6/7a1aba89-1d79-486f-8c82-ab7a8f8a58c2.png completed with 404 Not Found in 0.677355ms
web_1        | Cannot render console from 172.20.0.1! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255
web_1        | GET /serviceworker.js completed with 304 Not Modified in 15.124716ms

To Reproduce

1- Follow the installation with docker guide. 2- Access 127.0.0.1:3000

Expected behavior

Screenshots

1- 2- 3-

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• Browser: firefox
• Version: 70

Smartphone (please complete the following information):

• Device:
• OS:
• Browser:
• Version:

Additional context

Describe the bug Looks like currently we can create posts with "U+202D" (LEFT-TO-RIGHT OVERRIDE) and other Invisible unicode characters

Here's the post

• https://dev.to/anuraghazra/-12ef
• hashtags: https://dev.to/t/%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E https://dev.to/t/%E2%80%8E

To Reproduce

• Copy U+202D unicode character
• Create a new post and set title to U+202D character
  • Same with hastags, Canonical URL & Series.

Expected behavior Should not allow those invisible unicode characters

Screenshots

Desktop (please complete the following information):

• OS: Windows 7 64bit
• Browser: Chrome
• Version:

Additional context I also copy pasted characters from here http://emptycharacter.com/

Describe the bug If you change the email address in your profile, you keep getting email notifications on your previous address even after you have confirmed the new one

To Reproduce

1. Go to 'Settings > Profile'
2. Under 'User' section, change the email
3. Open email sent to new address and click 'confirm my account'
4. See error -> Keep getting email notifications on previous address

Expected behavior After confirmation of new email address, all email notifications should be sent to that address and not to the previous one

Desktop (please complete the following information):

• OS, version: Linux Mint 19.3
• Browser, version: 78.0.1 (64-bit)

Describe the bug

When first opening Dev.to (on both mobile & desktop) or when first visiting a new area (going to the dashboard from the homepage; starting a new post) the default theme is shown. This persists for a few page refreshes before my selected theme (night theme) is shown.

To Reproduce

1. Open a private/incognito browser window
2. Log in
3. The default theme is shown (instead of the one in settings)

Expected behavior

The theme selected in settings would show after logging in.

Screenshots

First screen after logging in:

Settings page (It was always set to Night Theme; pre-login):

Desktop (please complete the following information):

• OS, version: macOS Catalina 10.15.7
• Browser, version: Vivaldi 3.4.2066.90 (Stable channel) (x86_64)

Smartphone (please complete the following information):

• Device: Samsung Note 10+
• OS, version: Android 11.0
• Browser, version: Chrome 88.0.4324.93

Describe the bug

It's been happening quite often recently for me but I can't really tell how exactly this should be reproduced. It does work after refreshing the page, but then when I go to another post it's broken again.

Also, this is what's happening in the console:

To Reproduce

See above.

Expected behavior

Fo this component to work properly :)

Screenshots

See above.

Desktop (please complete the following information):

n/a

Smartphone (please complete the following information):

n/a

Describe the bug Comment boxes grow as you type but when you press submit they stay the size they were when they had content.

To Reproduce

• Go to a post
• Write a long comment
• Post the comment
• See the comment box is still large.

Expected behaviour I'd expect the comment box the shrink back down to it's original size.

Screenshots

Desktop (please complete the following information):

• OS, version: Window 10
• Browser, version: Chrome 89.0.4389.114

Additional context Another small bug that doesn't really cause any harm.

In https://github.com/forem/forem/pull/13235 we refactored how /search/chat_channels works by essentially removing "search" functionality and turning it into more of a "filter". As noted in the PR:

You'll notice I left everything in the Search namespace (the route, the controller, and the service naming). I originally started removing chat_channels from search all together since this behaves more like a filter than a search.

However, I discovered there are some JS components that are using this endpoint as an "index". I started refactoring everything, but it quickly got out of hand and out of scope for what this PR is intended to address. I also realized it may actually be nice to leave everything in the search namespace so that when we re-do the search for Connect in the future, it's a smoother experience.

With that said, since we have the ChatChannelsController and the ChatChannelMembershipsController each with index actions, I think the right move would be to move those JS components to them so we don't have multiple controllers performing the same actions.

This issue is to essentially update all the JS components on the frontend to use a newly refactored endpoint that lives in a more appropriate spot (i.e. ChatChannelMembershipsController or ChatChannelsController) than the SearchController. Once this issue is complete, the chat_channels action should no longer exist in the SearchController and instead, a new endpoint should be able to take care of any "filtering" and "indexing" being done by the JS components.