Yup I think you're right about this being a regression because of `doContentUpdate`.
I'm not sure if what's in state is usable as a replacement to this.stories. I think redux does modification on it (spocs and deduping). Either way, it makes me nervous that we might start seeing 2 of the same spocs side by side by doing this. We generally only use store in specific cases in this file because of how much redux can change stories, iirc, but I can confirm.
Another options is, `doContentUpdate` just didn't send stories unless `fetchStories` updated something, because `this.stories` gets properly `transform`'d inside of fetchStories, it should have the blocked list.
An easier but less optimal option is to always run this.stories through a `.filter(s => !NewTabUtils.blockedLinks.isBlocked({"url": s.url}))` before `doContentUpdate` in system tick.
Bug 1528059 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Good find. Yup I think you're right about this being a regression because of `doContentUpdate`.
I'm not sure if what's in state is usable as a replacement to this.stories. I think redux does modification on it (spocs and deduping). Either way, it makes me nervous that we might start seeing 2 of the same spocs side by side by doing this. We generally only use store in specific cases in this file because of how much redux can change stories, iirc, but I can confirm.
Another options is, `doContentUpdate` just didn't send stories unless `fetchStories` updated something, because `this.stories` gets properly `transform`'d inside of fetchStories, it should have the blocked list.
An easier but less optimal option is to always run this.stories through a `.filter(s => !NewTabUtils.blockedLinks.isBlocked({"url": s.url}))` before `doContentUpdate` in system tick.