I papered over this in the short term by restarting daemons for all instances;
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 17 2017
We currently have three distinct selection states which I think are a little muddy. The first is the keyboard selection cursor, which shows what is selected with the keyboard:
@nemobis, can you walk me through the major differences you see between the proposal above and the support plans offered by other vendors like GitHub, GitLab, and Atlassian so I can make things more clear?
This is a productive environment, so I could not test to reproduce it and I don't know how can I reproduce it.
If I read this correctly, people would pay a certain amount regularly without any certainty or reasonable expectation to have any of the fixes or support they care about. Instead they'll need to rely on the resident haruspex to assess what they're embarking on.
Okay, but just to point out: having an apostrophe in one's name is not that exotic...
- O'Brien
- O'Connor
- D'Angelo
- O'Dowd
- O'Malley
- O'Hara
- D'Arcy
- D'Addario
So someone could quite conceivably have Chris.O'Dowd@BBC.co.uk or something like that.
Anyway, if anyone's looking for how to get around this in the future, an alternate solution to changing PhabricatorUserEmail.php would be to go into the DB phabricator_user, in table user_email, and change it directly in there, thus bypassing validation.
If you did want to change the code, though, look into http://php.net/manual/en/filter.examples.validation.php - FILTER_VALIDATE_EMAIL and FILTER_SANITIZE_EMAIL.
Per T12359, we aren't interested in supporting technically-deliverable-but-bizzarely-exotic addresses in the upstream. Feel free to fork to support this kind of address.
I've experienced the same error and it turns out that you need to give all privileges to all databases, not just phabricator. Hope it helps.
May 16 2017
Nice! The discussion is those two are interesting. Thanks for the links!
I've marked D17919 as fixing this although it only fixes the "hover with your mouse" half. A followup change will fix the "drag-to-select-a-range" half.
I marked D17919 as fixing this. I can't reproduce it after that change (except: the drag-select behavior isn't converted yet) and we're now Quicksand-aware, although it's possible I'm just not doing the right sequence of operations.
Interesting read. Indeed, our code is already committed and pushed (in feature branches), so Audit seems the way to go, but reviewing commits one by one is absolutely not the desired outcome.
Sorry, yes, that was a disappointing way to phrase it. You may open a thousand editors and put any number of them between zero and all of them, inclusive, into any of the various undo states.
only half of them :/
🐕
This no longer reproduces after D17916.
I'm inclined not to actually pursue the autofocus approach I was considering before, at least until we get a better read on whether click-to-select is a good behavior or not. Instead, I'm just going to fiddle with the UI a bit to fix the alignment issue. The new hidden inline state has some similar alignment issues.
(If something you care about got merged here and isn't covered at HEAD / by T12616, feel free to file a new report or feature request adhering to modern guidelines.)
I'm not sure this task has any specific, actionable issues remaining. Partly, it has just been open for twenty five decades and become a bit of a dumping ground.
I think it's also possible that this was T11784.
The keyboard reticle has been fixed but the inline reticle is still at large.
I think the keyboard reticle now generally has reasonable behavior.
max-height: 600px; overflow: scroll;
This is going to get even worse:
I've marked D17903 as fixing this. We still keep the comment focused, but comments no longer collapse en-masse after changes in T12616. Current state of the world is:
This discusses the hover/edit reticle, but the keyboard reticle has the same bug.
