Next

Summary

Although some images work, a lot of users are experiencing the comments poster, not allowing them to post. Some of these reports are manifestations of #1366, users are definitely experiencing a different bug to this.

I believe this to likely be related to state changes on the front-end.

https://www.minds.com/newsfeed/994278672455299072

Steps to reproduce

1. Go to a comments thread
2. Upload the below image
3. Try to post it. - See bug

(while you're here) 4. press delete on the attachment 5. try to post - you will not be able to.

Platform information

Reproduced Chromium / Manjaro

What is the current bug behavior?

The image can't be posted.

What is the expected correct behavior?

This should be seamless.

Relevant logs and/or screenshots

Possible fixes

As removing the image, it still cannot be posted, it feels to me like it is more likely to be a front-end state bug. No errors are outputted and the network logs seem to go through fine.

/label ~"T - Bug" ~"S - Triage:new"

added Triage::New Type::Bug (Triage) labels

changed the description

added Priority::0 - Urgent Product::Comments Type::Bug labels and removed Triage::New Type::Bug (Triage) labels

assigned to @benhayward.ben

changed milestone to %sprint: Interesting Iguana

changed weight to 3

added Status::InProgress label

The issue here is that the loading bar is not in sync with the actual progress of the request, if you click post and wait a short while for the request to end (look in dev tools if you can), you can post it fine.

More complicated than expected. Needed to set network speed down to 3g (slow) as otherwise the progress event only fires once, since localhost is so quick. It appears that 100% is being reported, before the XHR request is resolved.

One possible solution is to set the loading bar to a max of 95% on the progress event, and then have it jump to 100% upon completion via onload. This would allow our server some time to finish up the rest of its processing.

added Priority::1 - High label and removed Priority::0 - Urgent label

mentioned in commit c2a38f2c

I don't think this is as complicated as you think. Fixed with c2a38f2c, but we can keep open to reduce the 100% width until we get the attachment guid back.

added Priority::2 - Normal label and removed Priority::1 - High label

mentioned in commit 1793f0a3

mentioned in commit 0734f74b

mentioned in merge request !427 (merged)

closed via merge request !427 (merged)

mentioned in commit c6689ca3

mentioned in commit d7f9cc7d