6

While joking about the possibility to have a chat description so long that it would push the starboard offscreen, I actually noticed that the room info/description field seems to have a max length.

If you exceed that length an error is thrown (redirected to the generic chat error page). Now, I am not particularly worried about the error page, everyone should easily recognize what went wrong. The point is that the error page is suggesting that the error creates an automatic alert for the developers at Stack.

I think it may be worthy to add a check on the original page so that the error isn't thrown and we don't generate unneeded alerts.

Improve this question
5
  • Yep, client side validation or at least AJAXifying the submission would be great. :)
    – Shadow Wizard
    Commented Jul 6, 2015 at 12:24
  • @ShadowWizard even a simple client side validation would probably cut some of the alerts. Imagine if nicael reads this....
    – ꓢPArcheon
    Commented Jul 6, 2015 at 12:25
  • 1
    I'm 101% sure dear @nicael already tried that and saw that error page, though wonder why he didn't report it. Maybe not minor enough... ;)
    – Shadow Wizard
    Commented Jul 6, 2015 at 12:26
  • @Sha sure, I have seen it already :D
    – nicael
    Commented Jul 6, 2015 at 12:26
  • The limit is 500 chars. I dunno anyone needs to exceed this limit in common sense. And if it is exceeded - it does give the server error. The fix would be the client-side validation, as mentioned @Sha.
    – nicael
    Commented Jul 6, 2015 at 12:29

1 Answer 1

Reset to default
3

I have checked again and the bug is still there. I am now trusting this shouldn't be considered a top priority: no real damage is begin done, and the only result is (maybe) an automatic report in the SE back-end monitors / counters.

I am considering this closed as "deferred" for now - I don't know if it makes any difference for reporting and such, but if any mod want to put a deferred tag on the post it would be appreciated.

Improve this answer
4
  • 1
    Putting any status-tag on this is a good way for the report to get lost and never addressed at all. We tend to filter out status-* when looking at our internal dashboard.
    – Adam Lear StaffMod
    Commented Jan 14, 2016 at 21:10
  • @Adam in such case, why use the status-deferred to begin with?
    – Shadow Wizard
    Commented May 3, 2016 at 21:13
  • 1
    @ShadowWizard Because when the sites were first set up, someone thought it was a good idea, so it exists. It's also useful for us when we know an issue exists, but we don't need to keep it popping up in the dashboard. If a moderator decides to put a status tag on a post, they should assume it very likely won't get seen by an employee ever.
    – Adam Lear StaffMod
    Commented May 3, 2016 at 21:15
  • 1
    @Adam talking about this tag here in MSE, where every moderator is SE employee. There are currently 155 of these, one of them recently added by no other than David, SE VP of Engineering. Not expecting anything, I think the amount of deferred requests/bugs that turned to completed is less than the fingers in one hand, but still, looks like it's still being used. (And personally/honestly think it's indeed better not to use it here on this one, I'm just talking about the general case since you brought it up)
    – Shadow Wizard
    Commented May 3, 2016 at 21:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .