Summary: See Q335. This might need some tweaking, but the JS works now so we can move/style the node now.
Test Plan:
{F1169168}
- Also dragged stuff around, saw counts update properly.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15462
Summary:
This fix further addresses T10229. The problem and solution are the same:
- If the DOM is mutated during a touch, it never registers as a 'click' so the tapped button does not activate.
- This was partially addressed in D15136, which covered taps on code lines in a Differential view.
- Tapping on some buttons, like "Reply" or "Hide Comment" still caused the problem by showing a tooltip.
- There are probably similar buttons elsewhere, other than in Differential, exhibiting the same 'needs multiple taps to work' behaviour.
- The testing in the iOS simulator performed for D15136 did not reveal that the problem with "Hide comment" and such remained because the small device size used for testing triggered the `!= 'desktop'` path for tooltips.
To fix it:
- Don't show tooltips for touch events. You can't 'hover' with a finger (with today's tech) so that UI paradigm doesn't apply.
- Show the tooltips for regular mouse events, even if they are on the same device. Some devices have both touch and a mouse.
- No longer try to rely on a distinction between 'desktop' and 'mobile' devices. Mobile devices like the iPad Pro are essentially desktop like, and as mentioned above, a single device could be both touch and mouse enabled. It's not about the nature of the device, it's about the nature of the interaction.
Test Plan:
- Tapped "Hide Comment", "Reply" on an iPad Pro running iOS 9.2 and got single touch responses with no tooltips.
- Tried the same on an iPhone 6 running iOS 9.2.
- Hovered over the same on a regular desktop in Safari and saw tooltips. Clicked and saw regular reactions.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15310
Summary:
These columns were conflating `projectPHID` (the defualt project to add to the task) with `boardPHID` (the board the column appears on).
Separate them to fix the beahvior.
Test Plan: Used "Add Task" from dropdown menu of a milestone column on a parent project's workboard.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15242
Summary: Ref T4427.
Test Plan:
- Dragged a 17 XP task from "Hunting" to "Slain".
- Saw 17 XP move.
- Level up!
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4427
Differential Revision: https://secure.phabricator.com/D15237
Summary:
Ref T4900. Briefly:
- Much more layout and rendering is now done in Javascript.
- This should otherwise be identical to the behavior at HEAD, except that:
- editing a task and removing the current board from it no longer removes the task; and
- points still don't work.
However, this can now plausibly support realtime workboard updates and other complex state-based behaviors like points calculations in a future change.
Test Plan:
- Changed card covers.
- Moved cards.
- Sorted board by priority and natural.
- Added new cards.
- Edited cards in place.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D15234
Summary:
Ref T4900. To eventually support realtime board updates, we need to be able to perform a board state update without the context of the action which caused it.
For example, if the server says "update card Y", we need to know what to do without being told "card Y was moved from column A to column B" explicitly. Currently, all the update code relies on knowing what happened and which nodes were affected.
This is only a small step forward, but starts making things a bit more independent and consistent.
Test Plan:
- Moved cards around.
- Changed card cover images.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D15228
Summary:
Ref T4900. The root problem is that dragging stuff near the bottom of the board can cause jittery, jumpy behaviors.
Internal scrolling has changed the nature of this problem. Previously, the height of the board itself would jump around, but it's now fixed so the height of columns jumps around instead.
We could take the same approach and add a chunk to the bottom of each column when a drag starts, but this is really distracting visually since it's obvious to the user.
Instead, treat columns as infinitely tall (so dragging beneath them still counts as dragging to the bottom position).
Test Plan:
- View a board with a column taller than the screen (has a scrollbar).
- Drag a card to near the bottom position.
- Move the mouse down a little bit at a time, continuing toward the bottom of the page.
- Before patch: at some point, UI flips out and starts rapidly adding, scrolling, and removing the ghost.
- After patch: sensible behavior, ghost is in bottom position for all cursor locations.
Also works for dragging to the top.
(This leaves us with a little less dead space for cancelling drags, but you've still got the left menu, anything offscreen, and the escape key, which seems fine.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D15227
Summary:
Ref T4900. This gets moves on the new stuff and cleans them up a little.
Two behaviors haven't been ported yet: height adjustment during drags (which is broken anyway with inner scroll) and updating point counts (coming soon).
Test Plan: Dragged cards around on a board, including top/bottom positions and normal/priority sort.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D15226
Summary: Ref T4900. Continuing to move this over into a more structured approach.
Test Plan: Panned a workboard.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D15225
Summary:
Ref T4900. Broadly, workboard state management is fairly ad-hoc now, which makes things like this (where some kind of edit affects global state) difficult:
- Updating points header to reflect a sum change after dragging a task.
- Changing progress bars after editing a task to change resolution or points value.
- Moving a card to the correct column after editing it and changing subprojects/iterations.
- Responding to real-time notifications about other users moving cards.
This begins rewriting the code in a way that can better accommodate these kinds of far-reaching state update.
This change just moves cover image stuff. I'll continue moving features one at a time until boards work better.
Test Plan: Updated some cover images.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4900
Differential Revision: https://secure.phabricator.com/D15224
Summary:
Ref T4427.
- New config option for labels, enabling, etc., but no UI/niceness yet.
- When enabled, add a field.
- Allow nonnegative values, including fractional values.
- EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code.
Test Plan:
- Edited points via "Edit".
- Edited points via Conduit.
- Edited points via stacked actions.
- Tried to set "zebra" points.
- Tried to set -1 points.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4427
Differential Revision: https://secure.phabricator.com/D15220
Summary: This scroll lock thing prevented both X and Y scrolling, but should only prevent Y scrolling. Dragging a card to the edge to scroll left/right is fine.
Test Plan: Scrolled a workboard left/right by dragging a card to the edge.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15213
Summary:
Ref T5240. For boards with a lot of columns and users without "shift + mousewheel" or a touchpad, allow click-drag on the board background to pan the board horizontally.
The `ew-resize` cursor cue might be a little too intense. If it's annoying, we could drop it and just leave this as a secret feature to discover.
Test Plan: Panned the board horizontally.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D15211
Summary:
Ref T5240.
- Columns are fixed height.
- Columns scroll internally.
- Drag behaviors generally align with these column behaviors.
Test Plan: {F1099061}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D15209
Summary:
Currently, in Safari, if you drag an image onto a board to make it a cover file and then wave it around wildly a lot over differnent cards, it sometimes glitches out a bit and won't drop on them properly.
This appears to be because sequencing and delivery of dragenter/dragleave events isn't always totally ideal.
Instead, just cancel any existing drag when we get a new drag that targets a new drop target.
Test Plan:
- Opened a board with a bunch of cards.
- Dragged a file from my desktop onto the board.
- Waved it around wildly, hovering over many different cards.
- Before patch: sometimes cards under the cursor stopped highlighting properly.
- After patch: behavior seems correct and consistent.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15208
Summary: This was slightly more complex than I believed, but not too terrible.
Test Plan:
{F1096126}
- Also used some normal file uploaders to make sure I didn't break that.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15202
Summary:
Ref T10289. This probably doesn't cover everything but should do a little bit better.
Although we should mabye just exlude milestones from this menu completely?
Test Plan: {F1093937}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10289
Differential Revision: https://secure.phabricator.com/D15191
Summary:
Fixes T4136.
When listing projects in the "Visible To" selector control:
- Instead of showing every project you are a member of, show only a few.
- Add an option to choose something else which isn't in the menu.
- If you've used the control before, show the stuff you've selected in the recent past.
- If you haven't used the control before or haven't used it much, show the stuff you've picked and them some filler.
- Don't offer milestones.
- Also don't offer milestones in the custom policy UI.
Test Plan:
{F1091999}
{F1092000}
- Selected a project.
- Used "find" to select a different project.
- Saw reasonable defaults.
- Saw favorites stick.
- Tried to typeahead a milestone (nope).
- Used "Custom Policy", tried to typeahead a milestone (nope).
- Used "Custom Policy" in general.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4136
Differential Revision: https://secure.phabricator.com/D15184
Summary:
Ref T10010. These aren't perfect but I think (?) they aren't horribly broken.
- When a project is a parent project, destroy (as far as the user can tell) any custom columns.
- When a project has milestones, automatically generate columns on the project's workboard (if it has a workboard).
- When you move tasks between milestones, add the proper milestone tag.
- When you move tasks out of milestones back into the backlog, add the proper parent project tag.
- (Plenty of UI / design stuff to adjust.)
Test Plan:
- Dragged stuff between milestone columns.
- Used a normal workboard.
- Wasn't able to find any egregiously bad cases that did anything terrible.
{F1088224}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10010
Differential Revision: https://secure.phabricator.com/D15171
Summary: No UI changes, just some search and replace for UI consistency.
Test Plan: Test person and object hovercards still work. UIExamples too.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15172
Summary:
Ref T5240. This probably has some bugs and doesn't quite work in Firefox (fine on boards, not quite on the task list -- some issue with body or document being special, I think).
I think this is close enough that we can throw it out there and see how users manage to break it, though. It's not worse than what we've got now? I think?
Test Plan:
dragged things near the edge of other things
they seemed to move around OK
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D10188
Summary:
Ref T5240.
- Add proper class when dropping cards.
- Add proper class when creating new cards.
- Make X-drag explicit so that it works if there's only one column.
- Stop tootips when dragging, resume them after dropping.
- Move CSS rule for consistency.
- Allow user to hit "Escape" to cancel an in-progress drag.
Test Plan:
- Dropped cards.
- Created new cards.
- X-dragged on a workboard with one column and a dashboard.
- Dragged over a tooltip (no tip), dropped, moused over tooltip (tip).
- Hit escape during a drag.
Reviewers: chad
Reviewed By: chad
Subscribers: cspeckmim
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D15163
Summary:
Ref T5240. Currently, when dragging nodes, we leave them where they are in the document and apply "position: relative;" so we can move them around on screen.
- Pros: All the CSS still works.
- Cons: Can't drag them outside the nearest containing element with "overflow: hidden;", many subtle positioning bugs with scrollable containers.
Instead, this diff leaves the thing we're dragging exactly where it is, clones it, and drags the clone instead.
- Pros: You can drag it anywhere. Seems to fix all the scrolling container problems.
- Cons: CSS which depends on a container class no longer works.
The CSS thing is bad, but doesn't seem too unreasonable to fix. Basically, we just need to put some `phui-this-is-a-workboard-card` class on the cards, and use that to style them instead of `phui-workboard-view`, and then do something similar for draggable lists.
Although we no longer need to drag cards to tabs with the current design, I think there's a reasonable chance we'll revisit that later. The current design also calls for scrollable columns, but there would be no way to drag cards outside of their current column with the current approach.
NOTE: This does not attempt to fix the CSS, so dragging is pretty rough, since the "clone" loses a number of container classes and thus a number of rules. I'll clean up the CSS in the next change.
Test Plan:
- Dragged stuff around on task lists, workboards, and sort lists (e.g., pinned applications) in Safari, Firefox and Chrome.
- Scrolled window and containers (workboards) during drag.
- Dragged stuff out of the workboard.
- Dragged stuff offscreen.
- CSS is funky, but I can no longer find any positioning or layout issues in any browser.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D15160
Summary: Ref T5240. This property does nothing.
Test Plan: Search, drag a card around.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D15159
Summary:
Ref T5240. Currently, we calculate drag positions assuming the "ghost" element is not present (it isn't, usually), then adjust them while dragging to account for the ghost.
However, this fails after scrolling: we dirty the cache, but the ghost //is// present. We continue adjusting for it, but essentially double-adjust. This leads to scroll positions being about 80-ish px off from where they should be.
Test Plan:
- Begin dragging a task in a long task list.
- While dragging, use mousewheel to scroll to the bottom of the list.
- Drag task downward through the list.
- Before fix: ghost is off by, like, an inch or so.
- After fix: ghost position is accurate to cursor position.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T5240
Differential Revision: https://secure.phabricator.com/D15157
Summary:
Mostly, this has just been sitting in my sandbox for a long time. I may also touch some charting stuff with subprojects/milestones, but don't have particular plans to do that.
D3 seems a bit more flexible, and it's easier to push more of the style logic into CSS so you can fix my design atrocities. gRaphael also hasn't been updated in ~3+ years.
Test Plan:
{F1085433}
{F1085434}
Reviewers: chad
Reviewed By: chad
Subscribers: cburroughs, yelirekim
Differential Revision: https://secure.phabricator.com/D15155
Summary:
Fixes T10229. Broadly:
- When the user hovers over a line number or inline comment, we update the yellow reticle to highlight the relevant lines. Specifically, this is in response to a `mouseover` event.
- On touch devices, touches fire `mouseover` and if you mutate the DOM inside the event, the device aborts the touch.
To remedy this:
- Distingiush between mouse-originated and touch-originated cursor events.
- We do this, roughly, by setting a flag when we see "touchstart", and clearing it when we see the second copy of any unique cursor event.
- This method is complex, but should be robust to any implementation differences between devices (for example, it will work no matter which order the events are fired in).
- This method should also produce the correct results on weird devices that have both mouse-devices and touch-devices available for cursor input.
- When we see a touch-originated `mouseover` or `mouseout`, don't mutate the DOM.
- Put an extra DOM mutation into the `click` event to improve highlighting behavior on touch devices.
Test Plan:
- In iOS Simulator (4s, iOS 9.2), clicked various inline actions ("Reply", "Hide", "Done", "Cancel", line numbers, etc). Got responses after a single touch.
- Verified hover + click behavior on a desktop.
- Logged and examined a bunch of events as a general sanity check.
Reviewers: chad
Reviewed By: chad
Subscribers: aljungberg
Maniphest Tasks: T10229
Differential Revision: https://secure.phabricator.com/D15136
Summary: Ref T10229. Fixes T9969. We make a decision about 1up vs 2up pretty early, and sometimes the viewport size reads as larger than the device, so we incorrectly select 2up when the proper setting would be 1up.
Test Plan:
I can reproduce this by, e.g., reloading a lot on an iPhone 4s in iOS Simulator running iOS 9.2. Sometimes it picks 2-up. I added logging to show that the viewport dimension read was the issue.
After this change, it always selects 1-up (`window.screen.availWidth` is defined and sensible on the device).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9969, T10229
Differential Revision: https://secure.phabricator.com/D15135
Summary: Ref T10163. These are almost certainly not username/project characters, and are fairly likely to be `@{...}` Diviner references.
Test Plan: Typed `@{...`, no more autocomplete.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15110
Summary:
The text sliding around feels a bit jank to me. Instead, here's an attempt at a three-part effect:
- Fade out the content of the menu (first quarter of the animation).
- Shrink the menu (half the animation).
- Fade the menu content back in (final quarter).
This isn't perfect, but feels less weird to me since the text doesn't dance?
Test Plan: clickey clickey
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15098
Summary:
Fixes T10190. This is still a touch weird (newly typed tokens lose icons when copied) but basically works correctly. Saving/editing rules is fine, just some minor display glitching.
Fixing the icon thing is a little more involved.
Test Plan: Swapped Herald tokenizer fields around saw values (approximately) preserved.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10190
Differential Revision: https://secure.phabricator.com/D15077
Summary:
Ref T10054. This fix is a little rough but the "right" fix involves a ton of rewriting to `AphrontSideNavFilterView` and I don't want to open that can of worms up yet.
Specifically, the problem is:
- we build the menu in order to populate the mobile/application menu;
- as a side effect of building the menu (not rendering the menu), we initialize the menu collapse/expand behavior;
- but we never actually render the menu, so the `JX.$()` call fails.
The right fix would be to initialize the behavior only when we render the menu, but then `AphorntSideNavFilterView` would need to know about profile menu behaviors. It probably should some day, but I think today is not that day.
Test Plan: Set icons on a link on a profile menu.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10054
Differential Revision: https://secure.phabricator.com/D15073
Summary:
Ref T10054. I think this gets everything except:
- circles on icons;
- I spent ~15 minutes poking at animations but wasn't able to get anything that looked reasonable whatsoever.
Test Plan:
- Collapsed menus.
- Expanded menus.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10054
Differential Revision: https://secure.phabricator.com/D15056
Summary: These are old project image choices, remove and only go with FontAwesome related images.
Test Plan: Project -> Edit Picture -> Save
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15051
Summary:
Ref T10163. If you right-click the suggestion menu, just eat it. I don't think we can really choose a different behavior reasonably, or that users have any reason to do this.
I'm leaving "clicking the header dismisses it", I think that behavior is fine and reasonable.
Test Plan: Control-clicked a suggestion menu, didn't trigger a suggestion.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15042
Summary: Ref T10163. When a user autocompletes, add a space for them, unless they already added a comma, colon, or space themsevles.
Test Plan: Autocompleted `@dog`, got `@dog `. Autocompleted `@epriestley,` got `@epriestley,`.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15041
Summary:
Ref T10163. Currently, we don't activate on indented lines, but were too aggressive about this, and would not activate on lines like ` - Hey, @user...`, where we should.
Instead, don't activate on indented lines if there's only an indent (i.e., `#` probably means enumerated list).
Also, if results don't have autocompletes (rare but possible with projects missing slugs), improve behavior.
Test Plan:
- Typed ` #a`, got no autocomplete.
- Missing slug thing is a pain to test locallly, `#1 z z z z` reproduces in production. I'll just verify it there.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15040
Summary:
Ref T10163. When we think the user has finished typing a word (because they typed a space, period, or other similar characters) and nothing else they might type could possibly change the outcome (usually because the words they have typed already match nothing), just deactivate the autocomplete.
As a special case, if the word they have typed already select exactly one result, //and// they have already typed exactly that result, assume they just typed it from memory and deactivate.
Test Plan:
- Typed `@dog qwer zxcv` and saw autocomplete deactivate on the space before `z` (on my local install, `@dog` is ambiguous but `@dog qwer` matches nothing).
- Typed `@epriestley ` and saw autocomplete deactivate on space.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15039
Summary: Ref T10163. In cases like Conpherence, the autocompleter can currently render off the bottom of the screen. Put it above if it would be offscreen.
Test Plan: {F1062286}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15038
Summary: Ref T10163. Activate on `@d`, not just `@`. Note that if you type `@d` and then press delete once so you're left with `@`, we stay active (and show the "type a username" hint).
Test Plan:
- Typed `@`, no completer.
- Typed `d`, got completer.
- Typed delete, still had completer, now showing hint prompt.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15037
Summary:
Ref T10163. Some characters are almost certainly punctuation or markup rather than autocomplete requests. Immediately cancel any active autocomplete when the user types one of these.
Note that some of these are also suffix characters. If you type `@dog,`, you have until the next character to decide you actually mean to autocomplete. Once you type something else we deactivate.
If you type `#dog#` or `##`, we deactivate immediately.
Test Plan: Typed `@dog#`, etc.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15036
Summary: Ref T10163. This allows activation in blockquotes or after `NOTE:`, for consistency.
Test Plan: Typed `>@dog`, etc., got autocomplete.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15035
Summary:
Ref T10163.
- If a user types an autocomplete character ("@" or "#") and then a space, deactivate immediately (probably an ordered list).
- If a user types an autocomplete character indented on a line with no other prior text, don't activate (probably an ordered list or code block).
Test Plan:
Typed:
- `# `, saw immediate deactivation.
- ` #`, saw no activation in the first place.
- `#x`, saw activation.
- `asdf #x`, saw activation.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15033
Summary: Ref T10163. I would still sometimes not get a replacement after clicking with the delayed blur. This seems to fix the issue more consistently: instead of listening for a click event (which fires after the blur), listen for a mousedown event (which fires before the blur).
Test Plan: Observed consistent selection via mouse locally.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15032
Summary:
Ref T10163.
- If you click a result, we get a blur before your click hits, and deactivate before the click can work. Instead, wait before responding to blur.
- Use the standard sort handler which puts unixnames over human names. Also use the standard filter which deals with disabled users not matching unless they're the only match.
Test Plan:
- Clicked a result, got a replacement.
- Named myself "dog dog", typed "@dog", user "@dog" was now first match despite me being "@admin".
- Used normal typeaheads to make sure I didn't break sort handler.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15031
Summary: Ref T3725. This probably has 900,000 bugs. This will need updates for subprojects/milestones.
Test Plan:
- Tested very gently in Safari, Firefox and Chrome.
- Reasonable inputs appear to work.
- Clicking, escape, tab, return, arrow keys work OK?
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T3725
Differential Revision: https://secure.phabricator.com/D15029
Summary: Ref T10054. Allows users to drag menu items to reorder them.
Test Plan: Reordered a project menu.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10054
Differential Revision: https://secure.phabricator.com/D15011
Summary: Fixes T10139. This clarification seems reasonable to me.
Test Plan:
- Viewed a revision with context.
- Clicked "Show All Context".
- Saw "All Context Shown".
{F1060624}
{F1060625}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10139
Differential Revision: https://secure.phabricator.com/D15009
Summary: Fixes T10116.
Test Plan:
- Prior to patch: Control/Command + Enter submitted form but ignored actions.
- After patch: verifid command + enter submits actions.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10116
Differential Revision: https://secure.phabricator.com/D14991
Summary:
Ref T10010. Ref T5819. General alignment of the stars:
- There were some hacks in Conduit around stripping `fa-...` off icons when reading and writing that I wanted to get rid of.
- We probably have room for a subtitle in the new heavy nav, and using the icon name is a good starting point (and maybe good enough on its own?)
- The project list was real bad looking with redundant tag/names, now it is very slightly less bad looking with non-redundant types?
- Some installs will want to call Milestones something else, and this gets us a big part of the way there.
- This may slightly help to reinforce "tag" vs "policy" vs "group" stuff?
---
I'm letting installs have enough rope to shoot themselves in the foot (e.g., define 100 icons). It isn't the end of the world if they reuse icons, and is clearly their fault.
I think the cases where 100 icons will break down are:
- Icon selector dialog may get very unwieldy.
- Query UI will be pretty iffy/huge with 100 icons.
We could improve these fairly easily if an install comes up with a reasonable use case for having 100 icons.
---
The UI on the icon itself in the list views is a little iffy -- mostly, it's too saturated/bold.
I'd ideally like to try either:
- rendering a "shade" version (i.e. lighter, less-saturated color); or
- rendering a "shade" tag with just the icon in it.
However, there didn't seem to be a way to do the first one right now (`fa-example sh-blue` doesn't work) and the second one had weird margins/padding, so I left it like this for now. I figure we can clean it up once we build the thick nav, since that will probably also want an identical element.
(I don't want to render a full tag with the icon + name since I think that's confusing -- it looks like a project/object tag, but is not.)
Test Plan:
{F1049905}
{F1049906}
Reviewers: chad
Reviewed By: chad
Subscribers: 20after4, Luke081515.2
Maniphest Tasks: T5819, T10010
Differential Revision: https://secure.phabricator.com/D14918
Summary:
Fixes T9323. Two minor fixes:
- On the first commit, don't render a downward line.
- Clean up a 1px spacing issue that had cropped up a while ago when we added icons or something, I think.
Test Plan:
Before:
{F1057248}
After:
{F1057249}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9323
Differential Revision: https://secure.phabricator.com/D14974
Summary: Ref T10004. This control doesn't disable visually or behaviorally, e.g. when locked in an EditEngine configuration.
Test Plan:
- Locked field for Projects.
- Reviewed form in EditEngine.
- Created/edited a project.
- Swapped default.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14911
Summary: Ref T10004. This primarily supports moving Phame to EditEngine.
Test Plan: {F1045166}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14887
Summary: I'll revert this within 24 hours, before I promote.
Test Plan: Had completely functional but greatly enhanced Phabricator experience in Firefox, Safari and Chrome.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D14884
Summary: Ref T8980. Previously, if you had like `T123T123T123` and waved your mouse over them, we wouldn't move the card. Now, move the card.
Test Plan: Waved mouse. Saw the card move.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8980
Differential Revision: https://secure.phabricator.com/D14881
Summary: Ref T8980. This calculation was not quite right and you could sneak one off screen if you tried carefully.
Test Plan: Couldn't sneak one off screen anymore.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8980
Differential Revision: https://secure.phabricator.com/D14880
Summary:
Ref T8980. Move away from events to EngineExtensions.
This also simplifies hovercards a bit:
- Removes tasks from revision cards.
- Removes blockers/blocked from task cards.
- Removes "Send Message" from user cards.
These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns).
Test Plan:
- Viewed people, task, revision, commit and project hovercards.
{F1043256}
{F1043257}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8980
Differential Revision: https://secure.phabricator.com/D14878
Summary:
Ref T10004. This might be a little too funky or magical, but is probably not necessary too often and easier than doing new layout with the CSS.
Also make the desktop icons a little meatier.
Test Plan: Swiped things away on mobile. Clicked things away on desktop.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14857
Summary:
Fixes T1895. Now that we have on-demand prviews, we can use them on mobile. On mobile:
- don't show live previews;
- only save drafts every 10 seconds.
Also, show fewer remarkup buttons on mobile to try to make sure the more important ones (preview, e.g.) fit.
Test Plan:
- Made window narrower and wider to trigger preview/no-preview behavior.
- Used DarkConsole to verify request rate.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T1895
Differential Revision: https://secure.phabricator.com/D14856
Summary:
Ref T3967. This gives us a reasonable baseline for doing remarkup previews inline in all contexts, and works in weird/constrained context including:
- inline comments;
- conpherence; and
- custom fields.
It would be nicer to go beyond this in contexts like Phame posts, but this is a start, at least.
Test Plan:
{F1040877}
{F1040878}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T3967
Differential Revision: https://secure.phabricator.com/D14855
Summary:
Fixes T10039. We add text to textareas in two cases:
- Users clicking assitance buttons in Remarkup text areas.
- Drag-and-drop file uploads.
In case (1), it makes sense to highlight the text (it shows the user what we inserted, and lets them undo the action easily if it isn't what they wanted).
In case (2), it does not. Users almost never want to delete or edit a file reference. It is slightly nice to have the reference as a visual callout, but I don't think this is a big deal.
Change the behavior so that we highlight only for remarkup buttons, not for drag-and-drop files.
Test Plan:
- Clicked an "isnert quote" button on remarkup assist area, got highlighted example text.
- Dragged and dropped a file, got text inserted with no highlight.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10039
Differential Revision: https://secure.phabricator.com/D14851
Summary: Fixes T9871. Ref T10004. These won't win any awards but it fixes them being incredibly weird and confusing.
Test Plan:
{F1029090}
- Tried to use controls, got reasonable behavior.
- Used normal controls to make sure I didn't break anything.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9871, T10004
Differential Revision: https://secure.phabricator.com/D14814
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.
In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.
See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.
ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.
Finally, we have better tools for fixing the default behavior now than we did in 2013.
Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.
In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.
I'll remove the `setObjectURI()` mechanism in the next diff.
Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10004
Differential Revision: https://secure.phabricator.com/D14804
Summary:
Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar.
This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code.
I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something.
Test Plan:
- Created events, projects and badges with custom icons.
- Edited events, projects and badges, changing their icons.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9992
Differential Revision: https://secure.phabricator.com/D14799
Summary:
Ref T9908. Fixes T6205.
This is largely some refactoring to improve the code. The new structure is:
- Each EditField has zero or one "submit" (normal edit form) controls.
- Each EditField has zero or one "comment" (stacked actions) controls.
- If we want more than one in the future, we'd just add two fields.
- Each EditField can have multiple EditTypes which provide Conduit transactions.
- EditTypes are now lower-level and less involved on the Submit/Comment pathways.
Test Plan:
- Added and removed projects and subscribers.
- Changed task statuses.
- In two windows: added some subscribers in one, removed different ones in the other. The changes did not conflict.
- Applied changes via Conduit.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T6205, T9908
Differential Revision: https://secure.phabricator.com/D14789
Summary:
Fixes T9995. I think letting users customize slugs is not a hugely compelling as a product feature, and this fixes the issue with slugs that have "/" characters in them and makes the move to EditEngine easier since I don't have to deal with the weird JS thing.
Instead, just generate slugs automatically. No more JS, no more separate field, things automatically update if you rename a blog, and now that URIs have IDs in them the old URI will still work after a rename.
Test Plan:
- Applied migration.
- Created new posts.
- Edited existing posts.
- Visited various posts.
- Created a post with a bunch of "/" in the title, things still worked fine.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9995
Differential Revision: https://secure.phabricator.com/D14792
Summary:
Ref T9132. Ref T9908. Puts reordering UI in place:
- For create forms, this just lets you pick a UI display order other than alphabetical. Seems nice to have.
- For edit forms, this lets you create a hierarchy of advanced-to-basic forms and give them different visibility policies, if you want.
Test Plan:
{F1017842}
- Verified that "Edit Thing" now takes me to the highest-ranked edit form.
- Verified that create menu and quick create menu reflect application order.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132, T9908
Differential Revision: https://secure.phabricator.com/D14704
Summary:
Fixes T7848. @jasonfsmitty discussed an issue in great detail there and in D14359, and I completely missed it. Specifically:
- If you save a "Change status to: Open" rule in Maniphest, and then edit it again, the token shows "Unknown Object (???)" instead of the correct token.
- That's because loadHandles() has no idea what to do with the value "open", since it's not a real PHID.
The way we render tokenizer tokens in Herald is quite hacky right now. Fortunately, I wrote a //slightly// better way for EditEngine yesterday or the day before. Use the slightly better way to fix the issue with D14359.
This could still be better than it is, but the badness is mostly hidden now and can be cleaned up later without impacting anything.
Test Plan: Edited a Herald rule with projects and status changes, saw proper tokens.
Reviewers: chad
Reviewed By: chad
Subscribers: jasonfsmitty
Maniphest Tasks: T7848
Differential Revision: https://secure.phabricator.com/D14682
Summary:
Ref T9132. Fixes T4580. Thhat might actually have been fixed a while ago or something since it describes a buggy/bad interaction which doesn't reproduce for me at HEAD.
This saves and restores all the stacked actions (subscribers, projects, etc) so that you don't lose anything if you close a window by accident.
Test Plan:
Added a bunch of actions in various states, reloaded the page, draft stuck around.
Submitted form, actions didn't stick around anymore.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4580, T9132
Differential Revision: https://secure.phabricator.com/D14675
Summary:
Ref T9132. We currently have an old preview/draft behavior and a new actions behavior.
Let the actions behavior do drafts/previews too, so we can eventually throw away the old thing.
This is pretty much just copying the old behavior into the new one, but with a few tweaks. The major change is that we submit all the stacked actions behavior now, so the preview reflects everything the change will do (and, soon, we can save it in the draft in a consistent way).
Also includes one hack-fix that I'll clean up at some point.
Test Plan: Added a bunch of stacked actions and observed meaningful previews.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14672
Summary:
Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think.
I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now.
Test Plan:
- Reassigned a task.
- Put a task up for grabs.
- No reassign on closed tasks.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14669
Summary: Ref T9132. Supports selects in stacked actions and adds "Change Status" + "Change Priority".
Test Plan: Changed status and priority from stacked actions.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14667
Summary: Ref T9132. Shhh this never happened shhhhhhh.
Test Plan: Selected multiple actions, saw them add at the bottom.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14664
Summary:
Ref T9132. Like D14659, I'll hold this until after the cut.
This swaps commenting in Maniphest over to EditEngine / stackable actions. New code doesn't have parity yet, although none of the things we're missing should technically be //strictly mandatory//. There's a list inline. I'll restore these in the next diffs.
Briefly -- comments, subscribers and projects work. Status, owners and priority do not yet.
Test Plan:
- Made comments and added subscribers and projects.
- Read through the old code to look for missing features and tried to document them all.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14663
Summary: Ref T9132. This still has a lot of rough edges but the basics seem to work OK.
Test Plan: {F1012627}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14653
Summary: Reuse PHUIMarkupPreviewView in Phame for consistency, less custom code. Also, doesn't work (JS issue).
Test Plan: New Post, Edit Post, Save Post
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D14552
Summary:
Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet.
You can now edit a form and:
- Retitle it;
- add a preamble (instructions on top of the form); and
- reorder the form's fields.
Test Plan:
{F974632}
{F974633}
{F974634}
{F974635}
{F974636}
Reviewers: chad
Reviewed By: chad
Subscribers: hach-que
Maniphest Tasks: T9132
Differential Revision: https://secure.phabricator.com/D14503
Summary:
Fixes T9675.
Fixes the calculation for the difference between the first day of the month and the first day of the week. It was previously possible for this to be negative, which caused the subsequent loop to hang the browser.
Test Plan:
- Set week to start on Sunday. Observed that the calendar still renders fine.
- Set week to start on Monday. Observed that the browser no longer hangs on November 2015.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin
Maniphest Tasks: T9675
Differential Revision: https://secure.phabricator.com/D14409
Summary:
Ref T182. Replace the total mess we had before with a sort-of-reasonable element.
This automatically updates using "javascript".
Test Plan:
{F901983}
{F901984}
Used "Land Revision", saw the land status go from "Waiting" -> "Working" -> "Landed" without having to mash reload over and over again.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T182
Differential Revision: https://secure.phabricator.com/D14314
Summary:
Ref T9524. Because fetching the last time files were modified in Diffusion can be slow, we bring it in over Ajax.
The logic to fetch and paint the table is kind of fragile because there are two different definitions of the columns right now and we break in a bad way if they differ.
In particular, calling `diffusion.updatecoverage` can populate a "lint commit" for a repository, which tries to generate lint information in one of the views (but not the other one).
In the longer run I think we're removing some of the concepts here and this rendering should be rebuilt to not have two separate column definitions, but just make it degrade gracefully for now since those are larger changes.
Test Plan:
Reproduced the issue in T9524 by calling `diffusion.updatecoverage` on a repostiory. Specifically, this has a side effect of creating a "lint commit" which triggers a "lint" column in this table, sort of.
Applied this patch, got a clean render.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9524
Differential Revision: https://secure.phabricator.com/D14243
Summary: Fixes T8572. Ideally we would probably just permit this, but clean up the behavior until the day arrives when inline code is actually rewritten.
Test Plan:
- Tried to launch editors in Differential and Diffusion while comments were already open.
- Verified that "Jump to inline" works in both cases.
{F788008}
{F788009}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8572
Differential Revision: https://secure.phabricator.com/D14094
Summary:
Ref T9324. When you upload a normal file, we call `willUpload` and then `didUpload`.
When you upload a chunked file, we never call `willUpload`. This can get things out of sync. Make sure we invoke this event for both chunked and non-chunked uploads.
Test Plan: Got cleaner behavior (redirect after all uploads finish) in new Phacility file upload area.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9324
Differential Revision: https://secure.phabricator.com/D14083
Summary: Fix T8710. I had hopes of doing something cleaver with `highlighted` (Like trying to understand `foo.bar` when clicking `bar`, but I obviously didn't do it.
Test Plan: ctrl-click.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: joshuaspence, epriestley, gena2x, Korvin
Maniphest Tasks: T8710
Differential Revision: https://secure.phabricator.com/D13550
Summary:
Fixes T8501.
When losing focus while holding ctrl, we never get a key-up event; ctrl-f/d/tab make the browser tab lose focus.
So treat 'blur' (unfocus) as if the user released ctrl.
Test Plan: ctrl-f/ctrl-d/ctrl-tab, ctrl-click-outside-of-window, and move mouse over the content - see no help suggestions.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley
Maniphest Tasks: T8501
Differential Revision: https://secure.phabricator.com/D13260
Summary: Ref T6920, This just removes the old voting UI from Ponder.
Test Plan: Visit a Question, no voting UI
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T6920
Differential Revision: https://secure.phabricator.com/D13827
Summary:
Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`.
I plan to obsolete and replace `HeraldCustomAction`.
Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T8726
Differential Revision: https://secure.phabricator.com/D13646
Summary:
Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized.
Instead, group and sort fields.
Test Plan: {F603066}
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T8726
Differential Revision: https://secure.phabricator.com/D13619
Summary: Ref T8726. This gets rid of all the `VALUE_*` constants and lets Fields provide arbitrary typeaheads without upstream/JS changes.
Test Plan: Used all tokenizers. Used "Another Herald Rule". Grepped for all removed constants.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8726
Differential Revision: https://secure.phabricator.com/D13616
Summary:
Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one.
This is ultimately the blocker for "select" custom fields working in Herald.
This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently).
Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8726
Differential Revision: https://secure.phabricator.com/D13613
Summary: Ref T8099, Fixes T8338. This allows re-ordering of Maniphest Tasks in the redesign. Somehow seems more fragile, but I couldn't break anything with it.
Test Plan: Try ordering into first position after header, last position, changing priority outright, everything I can drag.
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8099, T8338
Differential Revision: https://secure.phabricator.com/D13487
Summary: Fixes T8605, Popup datepicker should respect user preferred week start day
Test Plan: Edit event, open datepicker, calendar weeks should start on Sunday by default, and another day, if specified in User Preferences.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin
Maniphest Tasks: T8605
Differential Revision: https://secure.phabricator.com/D13419
Summary:
We use a non-standard way to invoke the edit dialogue (title, picture, etc) via the crumb. Stop doing that and instead use the widget technology to invoke the dialogue.
This requires making the widget handling code a bit more nuanced as nothing has wanted to pop a dialogue before. I plan to clean this up as I add the action to "Mark as Favorite" to the UI. In particular, I want to stop rendering the un-used DOM and make a workflow-based widget action a property as opposed to something hardcoded. This may be too ambitious depending on how similar these workflows are....
This also updates the ThreadSearchEngine to be a bit more modern. Additionally, go through making some user-facing strings a bit more sensical.
Test Plan: changed settings from conpherence full and durable column successfully.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D13449
