2011-02-02 00:52:04 +01:00
|
|
|
/**
|
|
|
|
* @provides javelin-behavior-differential-edit-inline-comments
|
Bring Javelin into Phabricator via git submodule, not copy-and-paste
Summary:
Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt
packages. This is not so great.
Pull it in as a submodule instead and make all the Phabriator resources declare
proper dependency trees. Add Javelin linting.
Test Plan:
I tried to run through pretty much all the JS functionality on the site. This is
still a high-risk change, but I did a pretty thorough test
Differential: inline comments, revealing diffs, list tokenizers, comment
preview, editing/deleting comments, add review action.
Maniphest: list tokenizer, comment actions
Herald: rule editing, tokenizers, add/remove rows
Reviewed By: tomo
Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen
CC: aran, tomo, epriestley
Differential Revision: 223
2011-05-04 00:11:55 +02:00
|
|
|
* @requires javelin-behavior
|
|
|
|
* javelin-stratcom
|
|
|
|
* javelin-dom
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
* javelin-util
|
Bring Javelin into Phabricator via git submodule, not copy-and-paste
Summary:
Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt
packages. This is not so great.
Pull it in as a submodule instead and make all the Phabriator resources declare
proper dependency trees. Add Javelin linting.
Test Plan:
I tried to run through pretty much all the JS functionality on the site. This is
still a high-risk change, but I did a pretty thorough test
Differential: inline comments, revealing diffs, list tokenizers, comment
preview, editing/deleting comments, add review action.
Maniphest: list tokenizer, comment actions
Herald: rule editing, tokenizers, add/remove rows
Reviewed By: tomo
Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen
CC: aran, tomo, epriestley
Differential Revision: 223
2011-05-04 00:11:55 +02:00
|
|
|
* javelin-vector
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
* differential-inline-comment-editor
|
2011-02-02 00:52:04 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
JX.behavior('differential-edit-inline-comments', function(config) {
|
|
|
|
|
|
|
|
var selecting = false;
|
|
|
|
var reticle = JX.$N('div', {className: 'differential-reticle'});
|
2015-03-07 21:19:45 +01:00
|
|
|
var old_cells = [];
|
2011-02-02 00:52:04 +01:00
|
|
|
JX.DOM.hide(reticle);
|
|
|
|
|
|
|
|
var origin = null;
|
|
|
|
var target = null;
|
|
|
|
var root = null;
|
|
|
|
var changeset = null;
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
|
|
|
|
var editor = null;
|
2011-02-02 00:52:04 +01:00
|
|
|
|
Don't mutate DOM on touch-originated cursor events in Differential
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
2016-01-29 14:21:41 +01:00
|
|
|
function updateReticleForComment(e) {
|
|
|
|
root = e.getNode('differential-changeset');
|
|
|
|
if (!root) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
var data = e.getNodeData('differential-inline-comment');
|
|
|
|
var change = e.getNodeData('differential-changeset');
|
|
|
|
|
|
|
|
var id_part = data.on_right ? change.right : change.left;
|
|
|
|
var new_part = data.isNewFile ? 'N' : 'O';
|
|
|
|
var prefix = 'C' + id_part + new_part + 'L';
|
|
|
|
|
|
|
|
origin = JX.$(prefix + data.number);
|
|
|
|
target = JX.$(prefix + (parseInt(data.number, 10) +
|
|
|
|
parseInt(data.length, 10)));
|
|
|
|
|
|
|
|
updateReticle();
|
|
|
|
}
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
function updateReticle() {
|
2015-01-27 16:11:20 +01:00
|
|
|
JX.DOM.getContentFrame().appendChild(reticle);
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
var top = origin;
|
|
|
|
var bot = target;
|
|
|
|
if (JX.$V(top).y > JX.$V(bot).y) {
|
|
|
|
var tmp = top;
|
|
|
|
top = bot;
|
|
|
|
bot = tmp;
|
|
|
|
}
|
2015-03-07 20:47:55 +01:00
|
|
|
|
|
|
|
// Find the leftmost cell that we're going to highlight: this is the next
|
|
|
|
// <td /> in the row. In 2up views, it should be directly adjacent. In
|
|
|
|
// 1up views, we may have to skip over the other line number column.
|
|
|
|
var l = top;
|
|
|
|
while (JX.DOM.isType(l, 'th')) {
|
|
|
|
l = l.nextSibling;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Find the rightmost cell that we're going to highlight: this is the
|
|
|
|
// farthest consecutive, adjacent <td /> in the row. Sometimes the left
|
|
|
|
// and right nodes are the same (left side of 2up view); sometimes we're
|
|
|
|
// going to highlight several nodes (copy + code + coverage).
|
|
|
|
var r = l;
|
|
|
|
while (r.nextSibling && JX.DOM.isType(r.nextSibling, 'td')) {
|
|
|
|
r = r.nextSibling;
|
2012-05-05 02:41:06 +02:00
|
|
|
}
|
2015-01-27 16:11:20 +01:00
|
|
|
|
2015-03-07 20:47:55 +01:00
|
|
|
var pos = JX.$V(l)
|
|
|
|
.add(JX.Vector.getAggregateScrollForNode(l));
|
|
|
|
|
|
|
|
var dim = JX.$V(r)
|
|
|
|
.add(JX.Vector.getAggregateScrollForNode(r))
|
|
|
|
.add(-pos.x, -pos.y)
|
|
|
|
.add(JX.Vector.getDim(r));
|
|
|
|
|
2015-01-27 16:11:20 +01:00
|
|
|
var bpos = JX.$V(bot)
|
|
|
|
.add(JX.Vector.getAggregateScrollForNode(bot));
|
|
|
|
dim.y = (bpos.y - pos.y) + JX.Vector.getDim(bot).y;
|
2011-02-02 00:52:04 +01:00
|
|
|
|
|
|
|
pos.setPos(reticle);
|
|
|
|
dim.setDim(reticle);
|
|
|
|
|
|
|
|
JX.DOM.show(reticle);
|
2015-03-07 21:19:45 +01:00
|
|
|
|
|
|
|
// Find all the cells in the same row position between the top and bottom
|
|
|
|
// cell, so we can highlight them.
|
|
|
|
var seq = 0;
|
|
|
|
var row = top.parentNode;
|
|
|
|
for (seq = 0; seq < row.childNodes.length; seq++) {
|
|
|
|
if (row.childNodes[seq] == top) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var cells = [];
|
|
|
|
while (true) {
|
|
|
|
cells.push(row.childNodes[seq]);
|
|
|
|
if (row.childNodes[seq] == bot) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
row = row.nextSibling;
|
|
|
|
}
|
|
|
|
|
|
|
|
setSelectedCells(cells);
|
|
|
|
}
|
|
|
|
|
|
|
|
function setSelectedCells(new_cells) {
|
|
|
|
updateSelectedCellsClass(old_cells, false);
|
|
|
|
updateSelectedCellsClass(new_cells, true);
|
|
|
|
old_cells = new_cells;
|
|
|
|
}
|
|
|
|
|
|
|
|
function updateSelectedCellsClass(cells, selected) {
|
|
|
|
for (var ii = 0; ii < cells.length; ii++) {
|
|
|
|
JX.DOM.alterClass(cells[ii], 'selected', selected);
|
|
|
|
}
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
function hideReticle() {
|
|
|
|
JX.DOM.hide(reticle);
|
2015-03-07 21:19:45 +01:00
|
|
|
setSelectedCells([]);
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
|
|
|
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
JX.DifferentialInlineCommentEditor.listen('done', function() {
|
2011-02-02 00:52:04 +01:00
|
|
|
selecting = false;
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
editor = false;
|
2011-02-02 00:52:04 +01:00
|
|
|
hideReticle();
|
2012-02-29 23:28:48 +01:00
|
|
|
set_link_state(false);
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
});
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2011-02-02 01:42:36 +01:00
|
|
|
function isOnRight(node) {
|
2011-02-02 00:52:04 +01:00
|
|
|
return node.parentNode.firstChild != node;
|
|
|
|
}
|
2011-02-02 22:48:52 +01:00
|
|
|
|
2011-02-02 01:42:36 +01:00
|
|
|
function isNewFile(node) {
|
|
|
|
var data = JX.Stratcom.getData(root);
|
|
|
|
return isOnRight(node) || (data.left != data.right);
|
|
|
|
}
|
2011-02-02 00:52:04 +01:00
|
|
|
|
|
|
|
function getRowNumber(th_node) {
|
|
|
|
try {
|
|
|
|
return parseInt(th_node.id.match(/^C\d+[ON]L(\d+)$/)[1], 10);
|
|
|
|
} catch (x) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-29 23:28:48 +01:00
|
|
|
var set_link_state = function(active) {
|
|
|
|
JX.DOM.alterClass(JX.$(config.stage), 'inline-editor-active', active);
|
|
|
|
};
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
JX.Stratcom.listen(
|
|
|
|
'mousedown',
|
|
|
|
['differential-changeset', 'tag:th'],
|
|
|
|
function(e) {
|
2015-09-10 20:36:38 +02:00
|
|
|
if (e.isRightButton() ||
|
2011-02-02 00:52:04 +01:00
|
|
|
getRowNumber(e.getTarget()) === undefined) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-09-10 20:36:38 +02:00
|
|
|
if (editor) {
|
|
|
|
new JX.DifferentialInlineCommentEditor(config.uri)
|
|
|
|
.setOperation('busy')
|
|
|
|
.setRow(editor.getRow().previousSibling)
|
|
|
|
.start();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (selecting) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
selecting = true;
|
|
|
|
root = e.getNode('differential-changeset');
|
|
|
|
|
|
|
|
origin = target = e.getTarget();
|
|
|
|
|
|
|
|
var data = e.getNodeData('differential-changeset');
|
2011-02-02 01:42:36 +01:00
|
|
|
if (isOnRight(target)) {
|
|
|
|
changeset = data.right;
|
Resolve great internal confusion about left vs right inline comments
Summary:
This code was just all kinds of wrong, but got all the common cases anyone cares
about correct.
- In edit-inline-comments.js, if isOnRight() is true, use data.right, not
data.left (derp).
- Set data.left correctly, not to the same value as data.right (derp derp).
- Set "isNewFile" based on $is_new, not $on_right (derp derp derp).
Test Plan:
- Added JS debugging code to print "OLD" vs "NEW" and "LEFT" vs "RIGHT".
Clicked the left and right sides of diff-vs-base and diff-vs-diff diffs,
verified output was accurate in all cases.
- Added comments to the left-display-side of a diff-of-diffs, saved them, they
showed up where I put them.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran, epriestley
Maniphest Tasks: T543
Differential Revision: https://secure.phabricator.com/D1567
2012-02-04 00:26:47 +01:00
|
|
|
} else {
|
|
|
|
changeset = data.left;
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
updateReticle();
|
|
|
|
|
|
|
|
e.kill();
|
|
|
|
});
|
|
|
|
|
|
|
|
JX.Stratcom.listen(
|
2015-03-07 21:19:45 +01:00
|
|
|
['mouseover', 'mouseout'],
|
2011-02-02 00:52:04 +01:00
|
|
|
['differential-changeset', 'tag:th'],
|
|
|
|
function(e) {
|
Don't mutate DOM on touch-originated cursor events in Differential
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
2016-01-29 14:21:41 +01:00
|
|
|
if (e.getIsTouchEvent()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-03-07 21:19:45 +01:00
|
|
|
if (editor) {
|
|
|
|
// Don't update the reticle if we're editing a comment, since this
|
|
|
|
// would be distracting and we want to keep the lines corresponding
|
|
|
|
// to the comment highlighted during the edit.
|
2011-02-02 00:52:04 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-03-07 21:19:45 +01:00
|
|
|
if (getRowNumber(e.getTarget()) === undefined) {
|
|
|
|
// Don't update the reticle if this "<th />" doesn't correspond to a
|
|
|
|
// line number. For instance, this may be a dead line number, like the
|
|
|
|
// empty line numbers on the left hand side of a newly added file.
|
|
|
|
return;
|
|
|
|
}
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2015-03-07 21:19:45 +01:00
|
|
|
if (selecting) {
|
|
|
|
if (isOnRight(e.getTarget()) != isOnRight(origin)) {
|
|
|
|
// Don't update the reticle if we're selecting a line range and the
|
|
|
|
// "<th />" under the cursor is on the wrong side of the file. You
|
|
|
|
// can only leave inline comments on the left or right side of a
|
|
|
|
// file, not across lines on both sides.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (e.getNode('differential-changeset') !== root) {
|
|
|
|
// Don't update the reticle if we're selecting a line range and
|
|
|
|
// the "<th />" under the cursor corresponds to a different file.
|
|
|
|
// You can only leave inline comments on lines in a single file,
|
|
|
|
// not across multiple files.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (e.getType() == 'mouseout') {
|
|
|
|
if (selecting) {
|
|
|
|
// Don't hide the reticle if we're selecting, since we want to
|
|
|
|
// keep showing the line range that will be used if the mouse is
|
|
|
|
// released.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
hideReticle();
|
|
|
|
} else {
|
|
|
|
target = e.getTarget();
|
|
|
|
if (!selecting) {
|
|
|
|
// If we're just hovering the mouse and not selecting a line range,
|
|
|
|
// set the origin to the current row so we highlight it.
|
|
|
|
origin = target;
|
|
|
|
}
|
|
|
|
|
|
|
|
updateReticle();
|
|
|
|
}
|
2011-02-02 00:52:04 +01:00
|
|
|
});
|
|
|
|
|
|
|
|
JX.Stratcom.listen(
|
|
|
|
'mouseup',
|
|
|
|
null,
|
|
|
|
function(e) {
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
if (editor || !selecting) {
|
2011-02-02 00:52:04 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
var o = getRowNumber(origin);
|
|
|
|
var t = getRowNumber(target);
|
|
|
|
|
|
|
|
var insert;
|
|
|
|
var len;
|
|
|
|
if (t < o) {
|
|
|
|
len = (o - t);
|
|
|
|
o = t;
|
|
|
|
insert = origin.parentNode;
|
|
|
|
} else {
|
|
|
|
len = (t - o);
|
|
|
|
insert = target.parentNode;
|
|
|
|
}
|
|
|
|
|
2015-03-05 23:11:51 +01:00
|
|
|
var view = JX.ChangesetViewManager.getForNode(root);
|
|
|
|
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
editor = new JX.DifferentialInlineCommentEditor(config.uri)
|
2015-03-08 23:27:16 +01:00
|
|
|
.setTemplates(view.getUndoTemplates())
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
.setOperation('new')
|
2015-03-08 21:04:38 +01:00
|
|
|
.setChangesetID(changeset)
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
.setLineNumber(o)
|
|
|
|
.setLength(len)
|
|
|
|
.setIsNew(isNewFile(target) ? 1 : 0)
|
|
|
|
.setOnRight(isOnRight(target) ? 1 : 0)
|
|
|
|
.setRow(insert.nextSibling)
|
2011-06-10 16:36:42 +02:00
|
|
|
.setTable(insert.parentNode)
|
2015-03-05 23:11:51 +01:00
|
|
|
.setRenderer(view.getRenderer())
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
.start();
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2012-02-29 23:28:48 +01:00
|
|
|
set_link_state(true);
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
e.kill();
|
|
|
|
});
|
|
|
|
|
|
|
|
JX.Stratcom.listen(
|
|
|
|
['mouseover', 'mouseout'],
|
2011-02-02 01:42:36 +01:00
|
|
|
'differential-inline-comment',
|
2011-02-02 00:52:04 +01:00
|
|
|
function(e) {
|
Don't mutate DOM on touch-originated cursor events in Differential
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
2016-01-29 14:21:41 +01:00
|
|
|
if (e.getIsTouchEvent()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
if (e.getType() == 'mouseout') {
|
|
|
|
hideReticle();
|
|
|
|
} else {
|
Don't mutate DOM on touch-originated cursor events in Differential
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
2016-01-29 14:21:41 +01:00
|
|
|
updateReticleForComment(e);
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
var action_handler = function(op, e) {
|
2012-02-29 23:28:48 +01:00
|
|
|
e.kill();
|
|
|
|
|
|
|
|
if (editor) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
var node = e.getNode('differential-inline-comment');
|
Don't mutate DOM on touch-originated cursor events in Differential
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
2016-01-29 14:21:41 +01:00
|
|
|
|
|
|
|
// If we're on a touch device, we didn't highlight the affected lines
|
|
|
|
// earlier because we can't use hover events to mutate the document.
|
|
|
|
// Highlight them now.
|
|
|
|
updateReticleForComment(e);
|
|
|
|
|
Add more keyboard navigation options for inline comments
Summary:
- Use n/p to jump between comments.
- Use r to reply to the selected comment.
- Use e to edit the selected comment.
Test Plan: Verified n, p, r, e, j, k, J, K, "click edit" and "click reply"
behavior in as many weird cases as I could come up with.
Reviewers: btrahan, jungejason, nh, cpiro, jl
Reviewed By: btrahan
CC: aran, btrahan, epriestley
Maniphest Tasks: T583
Differential Revision: https://secure.phabricator.com/D1308
2012-01-04 17:21:22 +01:00
|
|
|
handle_inline_action(node, op);
|
2013-05-19 02:04:22 +02:00
|
|
|
};
|
Add more keyboard navigation options for inline comments
Summary:
- Use n/p to jump between comments.
- Use r to reply to the selected comment.
- Use e to edit the selected comment.
Test Plan: Verified n, p, r, e, j, k, J, K, "click edit" and "click reply"
behavior in as many weird cases as I could come up with.
Reviewers: btrahan, jungejason, nh, cpiro, jl
Reviewed By: btrahan
CC: aran, btrahan, epriestley
Maniphest Tasks: T583
Differential Revision: https://secure.phabricator.com/D1308
2012-01-04 17:21:22 +01:00
|
|
|
|
|
|
|
var handle_inline_action = function(node, op) {
|
|
|
|
var data = JX.Stratcom.getData(node);
|
When deleting inline comments, offer "undo" instead of prompting
Summary:
Ref T2009. Ref T1460.
Fixes T2618. When users hit "Delete" on inline comments, delete immediately and offer them "Undo". If they delete indirectly (e.g., by clicking "Delete" from the preview at the bottom of the page), we still prompt them, because the "Undo" action either won't be available or may not be easy to find. This is a "refdelete".
Fixes T6464. This was just a mess. Make it not as much of a mess. It should work now. Pretty sure.
Fixes T4999. We did not refresh these links often enough to find targets for them, so they could race with content. Reevaluate them after loading new changes.
Test Plan:
- Deleted and undid deletion of inlines from main view and preview.
- Clicked "View" on inlines.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6464, T4999, T2618, T1460, T2009
Differential Revision: https://secure.phabricator.com/D12032
2015-03-10 01:27:51 +01:00
|
|
|
|
|
|
|
// If you click an action in the preview at the bottom of the page, we
|
|
|
|
// find the corresponding node and simulate clicking that, if it's
|
|
|
|
// present on the page. This gives the editor a more consistent view
|
|
|
|
// of the document.
|
2012-08-02 21:24:23 +02:00
|
|
|
if (JX.Stratcom.hasSigil(node, 'differential-inline-comment-preview')) {
|
When deleting inline comments, offer "undo" instead of prompting
Summary:
Ref T2009. Ref T1460.
Fixes T2618. When users hit "Delete" on inline comments, delete immediately and offer them "Undo". If they delete indirectly (e.g., by clicking "Delete" from the preview at the bottom of the page), we still prompt them, because the "Undo" action either won't be available or may not be easy to find. This is a "refdelete".
Fixes T6464. This was just a mess. Make it not as much of a mess. It should work now. Pretty sure.
Fixes T4999. We did not refresh these links often enough to find targets for them, so they could race with content. Reevaluate them after loading new changes.
Test Plan:
- Deleted and undid deletion of inlines from main view and preview.
- Clicked "View" on inlines.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6464, T4999, T2618, T1460, T2009
Differential Revision: https://secure.phabricator.com/D12032
2015-03-10 01:27:51 +01:00
|
|
|
var nodes = JX.DOM.scry(
|
|
|
|
JX.DOM.getContentFrame(),
|
|
|
|
'div',
|
|
|
|
'differential-inline-comment');
|
|
|
|
|
|
|
|
var found = false;
|
|
|
|
var node_data;
|
|
|
|
for (var ii = 0; ii < nodes.length; ++ii) {
|
|
|
|
if (nodes[ii] == node) {
|
|
|
|
// Don't match the preview itself.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
node_data = JX.Stratcom.getData(nodes[ii]);
|
|
|
|
if (node_data.id == data.id) {
|
|
|
|
node = nodes[ii];
|
|
|
|
data = node_data;
|
|
|
|
found = true;
|
|
|
|
break;
|
2012-08-02 21:24:23 +02:00
|
|
|
}
|
|
|
|
}
|
When deleting inline comments, offer "undo" instead of prompting
Summary:
Ref T2009. Ref T1460.
Fixes T2618. When users hit "Delete" on inline comments, delete immediately and offer them "Undo". If they delete indirectly (e.g., by clicking "Delete" from the preview at the bottom of the page), we still prompt them, because the "Undo" action either won't be available or may not be easy to find. This is a "refdelete".
Fixes T6464. This was just a mess. Make it not as much of a mess. It should work now. Pretty sure.
Fixes T4999. We did not refresh these links often enough to find targets for them, so they could race with content. Reevaluate them after loading new changes.
Test Plan:
- Deleted and undid deletion of inlines from main view and preview.
- Clicked "View" on inlines.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6464, T4999, T2618, T1460, T2009
Differential Revision: https://secure.phabricator.com/D12032
2015-03-10 01:27:51 +01:00
|
|
|
|
|
|
|
if (!found) {
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-10 02:41:47 +01:00
|
|
|
switch (op) {
|
|
|
|
case 'delete':
|
|
|
|
new JX.DifferentialInlineCommentEditor(config.uri)
|
|
|
|
.deleteByID(data.id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (op == 'delete') {
|
|
|
|
op = 'refdelete';
|
When deleting inline comments, offer "undo" instead of prompting
Summary:
Ref T2009. Ref T1460.
Fixes T2618. When users hit "Delete" on inline comments, delete immediately and offer them "Undo". If they delete indirectly (e.g., by clicking "Delete" from the preview at the bottom of the page), we still prompt them, because the "Undo" action either won't be available or may not be easy to find. This is a "refdelete".
Fixes T6464. This was just a mess. Make it not as much of a mess. It should work now. Pretty sure.
Fixes T4999. We did not refresh these links often enough to find targets for them, so they could race with content. Reevaluate them after loading new changes.
Test Plan:
- Deleted and undid deletion of inlines from main view and preview.
- Clicked "View" on inlines.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6464, T4999, T2618, T1460, T2009
Differential Revision: https://secure.phabricator.com/D12032
2015-03-10 01:27:51 +01:00
|
|
|
}
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-10 02:41:47 +01:00
|
|
|
}
|
When deleting inline comments, offer "undo" instead of prompting
Summary:
Ref T2009. Ref T1460.
Fixes T2618. When users hit "Delete" on inline comments, delete immediately and offer them "Undo". If they delete indirectly (e.g., by clicking "Delete" from the preview at the bottom of the page), we still prompt them, because the "Undo" action either won't be available or may not be easy to find. This is a "refdelete".
Fixes T6464. This was just a mess. Make it not as much of a mess. It should work now. Pretty sure.
Fixes T4999. We did not refresh these links often enough to find targets for them, so they could race with content. Reevaluate them after loading new changes.
Test Plan:
- Deleted and undid deletion of inlines from main view and preview.
- Clicked "View" on inlines.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6464, T4999, T2618, T1460, T2009
Differential Revision: https://secure.phabricator.com/D12032
2015-03-10 01:27:51 +01:00
|
|
|
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-10 02:41:47 +01:00
|
|
|
if (op == 'done') {
|
|
|
|
var checkbox = JX.DOM.find(node, 'input', 'differential-inline-done');
|
|
|
|
new JX.DifferentialInlineCommentEditor(config.uri)
|
|
|
|
.toggleCheckbox(data.id, checkbox);
|
|
|
|
return;
|
2012-08-02 21:24:23 +02:00
|
|
|
}
|
2011-04-15 03:08:10 +02:00
|
|
|
|
When a user hits "Reply", then "Cancel" on an inline comment (without typing),
don't show "Undo"
Summary: When a user hits "Reply" on an inline comment, doesn't type anything,
and then hits "Cancel", we incorrectly store the text of the comment the user is
replying to as the "original" text, and then detect that they've changed it when
they immediately cancel. Instead, store empty string as the original text.
Test Plan:
- Hit "Reply" and then "Cancel" on an inline comment. No undo now.
- Hit "Reply", typed some text, and then hit "Cancel". Got an undo which
restored my text.
Reviewers: tomo, jungejason, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, tomo
Differential Revision: 879
2011-08-31 20:28:48 +02:00
|
|
|
var original = data.original;
|
2015-03-08 21:04:38 +01:00
|
|
|
var reply_phid = null;
|
When a user hits "Reply", then "Cancel" on an inline comment (without typing),
don't show "Undo"
Summary: When a user hits "Reply" on an inline comment, doesn't type anything,
and then hits "Cancel", we incorrectly store the text of the comment the user is
replying to as the "original" text, and then detect that they've changed it when
they immediately cancel. Instead, store empty string as the original text.
Test Plan:
- Hit "Reply" and then "Cancel" on an inline comment. No undo now.
- Hit "Reply", typed some text, and then hit "Cancel". Got an undo which
restored my text.
Reviewers: tomo, jungejason, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, tomo
Differential Revision: 879
2011-08-31 20:28:48 +02:00
|
|
|
if (op == 'reply') {
|
|
|
|
// If the user hit "reply", the original text is empty (a new reply), not
|
|
|
|
// the text of the comment they're replying to.
|
|
|
|
original = '';
|
2015-03-08 21:04:38 +01:00
|
|
|
reply_phid = data.phid;
|
When a user hits "Reply", then "Cancel" on an inline comment (without typing),
don't show "Undo"
Summary: When a user hits "Reply" on an inline comment, doesn't type anything,
and then hits "Cancel", we incorrectly store the text of the comment the user is
replying to as the "original" text, and then detect that they've changed it when
they immediately cancel. Instead, store empty string as the original text.
Test Plan:
- Hit "Reply" and then "Cancel" on an inline comment. No undo now.
- Hit "Reply", typed some text, and then hit "Cancel". Got an undo which
restored my text.
Reviewers: tomo, jungejason, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, tomo
Differential Revision: 879
2011-08-31 20:28:48 +02:00
|
|
|
}
|
|
|
|
|
When deleting inline comments, offer "undo" instead of prompting
Summary:
Ref T2009. Ref T1460.
Fixes T2618. When users hit "Delete" on inline comments, delete immediately and offer them "Undo". If they delete indirectly (e.g., by clicking "Delete" from the preview at the bottom of the page), we still prompt them, because the "Undo" action either won't be available or may not be easy to find. This is a "refdelete".
Fixes T6464. This was just a mess. Make it not as much of a mess. It should work now. Pretty sure.
Fixes T4999. We did not refresh these links often enough to find targets for them, so they could race with content. Reevaluate them after loading new changes.
Test Plan:
- Deleted and undid deletion of inlines from main view and preview.
- Clicked "View" on inlines.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6464, T4999, T2618, T1460, T2009
Differential Revision: https://secure.phabricator.com/D12032
2015-03-10 01:27:51 +01:00
|
|
|
var row = JX.DOM.findAbove(node, 'tr');
|
2015-03-08 21:04:38 +01:00
|
|
|
var changeset_root = JX.DOM.findAbove(
|
|
|
|
node,
|
|
|
|
'div',
|
|
|
|
'differential-changeset');
|
|
|
|
var view = JX.ChangesetViewManager.getForNode(changeset_root);
|
|
|
|
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
editor = new JX.DifferentialInlineCommentEditor(config.uri)
|
2015-03-08 23:27:16 +01:00
|
|
|
.setTemplates(view.getUndoTemplates())
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
.setOperation(op)
|
|
|
|
.setID(data.id)
|
2015-03-08 21:04:38 +01:00
|
|
|
.setChangesetID(data.changesetID)
|
2012-03-10 01:04:25 +01:00
|
|
|
.setLineNumber(data.number)
|
|
|
|
.setLength(data.length)
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
.setOnRight(data.on_right)
|
When a user hits "Reply", then "Cancel" on an inline comment (without typing),
don't show "Undo"
Summary: When a user hits "Reply" on an inline comment, doesn't type anything,
and then hits "Cancel", we incorrectly store the text of the comment the user is
replying to as the "original" text, and then detect that they've changed it when
they immediately cancel. Instead, store empty string as the original text.
Test Plan:
- Hit "Reply" and then "Cancel" on an inline comment. No undo now.
- Hit "Reply", typed some text, and then hit "Cancel". Got an undo which
restored my text.
Reviewers: tomo, jungejason, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, tomo
Differential Revision: 879
2011-08-31 20:28:48 +02:00
|
|
|
.setOriginalText(original)
|
2011-06-10 16:36:42 +02:00
|
|
|
.setRow(row)
|
|
|
|
.setTable(row.parentNode)
|
2015-03-08 21:04:38 +01:00
|
|
|
.setReplyToCommentPHID(reply_phid)
|
|
|
|
.setRenderer(view.getRenderer())
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
.start();
|
2012-02-29 23:28:48 +01:00
|
|
|
|
|
|
|
set_link_state(true);
|
2013-05-19 02:04:22 +02:00
|
|
|
};
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-10 02:41:47 +01:00
|
|
|
for (var op in {'edit': 1, 'delete': 1, 'reply': 1, 'done': 1}) {
|
Add "Undo" for editing Differential inline comments
Summary:
When a user hits 'cancel' on a 'new', 'edit', or 'reply' operation, add a little
"Changes discarded. __Undo__" insert so they can get their change back. No undo
for delete since there's an explicit prompt. Once this lands we can make
'escape' work again to close dialogs.
This change started feeling really good when I was merging all the duplicate
code and making things more consistent, but by the time I started writing client
rendering it felt gross. I'm not really thrilled with it but I guess it's a step
forward? The feature seems pretty OK in practice. Let me know how much barfing
this causes and I can try to remedy the most acute concerns.
This also fixes a bug where replies always (?) appear on the 'new' side of the
diff (I think?).
Test Plan:
Applied 'new', 'edit', 'delete' and 'reply' operations, pressed 'cancel' and
'okay' in each case, with and without changing text where relevant. All
behaviors seem to conform with expectations, except that canceling out of 'edit'
without changing the text gives you an option to undo when it shouldn't really.
There's no super easy way to get at the original text right now.
Reviewed By: aran
Reviewers: aran, jungejason, tuomaspelkonen
CC: simpkins, aran, epriestley
Differential Revision: 406
2011-06-08 01:11:10 +02:00
|
|
|
JX.Stratcom.listen(
|
|
|
|
'click',
|
|
|
|
['differential-inline-comment', 'differential-inline-' + op],
|
|
|
|
JX.bind(null, action_handler, op));
|
|
|
|
}
|
2011-02-02 00:52:04 +01:00
|
|
|
|
Add more keyboard navigation options for inline comments
Summary:
- Use n/p to jump between comments.
- Use r to reply to the selected comment.
- Use e to edit the selected comment.
Test Plan: Verified n, p, r, e, j, k, J, K, "click edit" and "click reply"
behavior in as many weird cases as I could come up with.
Reviewers: btrahan, jungejason, nh, cpiro, jl
Reviewed By: btrahan
CC: aran, btrahan, epriestley
Maniphest Tasks: T583
Differential Revision: https://secure.phabricator.com/D1308
2012-01-04 17:21:22 +01:00
|
|
|
JX.Stratcom.listen(
|
|
|
|
'differential-inline-action',
|
|
|
|
null,
|
|
|
|
function(e) {
|
|
|
|
var data = e.getData();
|
|
|
|
handle_inline_action(data.node, data.op);
|
|
|
|
});
|
|
|
|
|
Allow inline comments to be individually hidden
Summary:
Ref T7447. Implements per-viewer comment hiding. Once a comment is obsolete or uninteresting, you can hide it completely.
This is sticky per-user.
My hope is that this will strike a better balance between concerns than some of the other approaches (conservative porting, summarization, hide-all).
Specifically, this adds a new action here:
{F435621}
Clicking it completely collapses the comment into a small icon on the previous line, and saves the comment state as hidden for you:
{F435626}
You can click the icon to reveal all hidden comments below the line.
Test Plan:
- Hid comments.
- Showed comments.
- Created, edited, deleted and submitted comments.
- Used Diffusion comments (hiding is not implemented there yet, but I'd plan to bring it there eventually if it works out in Differential).
Reviewers: btrahan, chad
Reviewed By: btrahan
Subscribers: jparise, yelirekim, epriestley
Maniphest Tasks: T7447
Differential Revision: https://secure.phabricator.com/D13009
2015-05-27 19:28:38 +02:00
|
|
|
// Respond to the user clicking the "Hide Inline" button on an inline
|
|
|
|
// comment.
|
|
|
|
JX.Stratcom.listen('click', 'hide-inline', function(e) {
|
|
|
|
e.kill();
|
|
|
|
|
|
|
|
var row = e.getNode('inline-row');
|
|
|
|
JX.DOM.hide(row);
|
|
|
|
|
|
|
|
var prev = row.previousSibling;
|
|
|
|
while (prev && JX.Stratcom.hasSigil(prev, 'inline-row')) {
|
|
|
|
prev = prev.previousSibling;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!prev) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
var comment = e.getNodeData('differential-inline-comment');
|
|
|
|
|
|
|
|
var slots = [];
|
|
|
|
for (var ii = 0; ii < prev.childNodes.length; ii++) {
|
|
|
|
if (JX.DOM.isType(prev.childNodes[ii], 'th')) {
|
|
|
|
slots.push(prev.childNodes[ii]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Select the right-hand side if the comment is on the right.
|
|
|
|
var slot = (comment.on_right && slots[1]) || slots[0];
|
|
|
|
|
|
|
|
var reveal = JX.DOM.scry(slot, 'a', 'reveal-inlines')[0];
|
|
|
|
if (!reveal) {
|
|
|
|
reveal = JX.$N(
|
|
|
|
'a',
|
|
|
|
{
|
|
|
|
className: 'reveal-inlines',
|
|
|
|
sigil: 'reveal-inlines'
|
|
|
|
},
|
|
|
|
JX.$H(config.revealIcon));
|
|
|
|
|
|
|
|
JX.DOM.prependContent(slot, reveal);
|
|
|
|
}
|
|
|
|
|
|
|
|
new JX.Workflow(config.uri, {op: 'hide', ids: comment.id})
|
|
|
|
.setHandler(JX.bag)
|
|
|
|
.start();
|
|
|
|
});
|
|
|
|
|
|
|
|
JX.Stratcom.listen('click', 'reveal-inlines', function(e) {
|
|
|
|
e.kill();
|
|
|
|
|
|
|
|
var row = e.getNode('tag:tr');
|
|
|
|
var next = row.nextSibling;
|
|
|
|
|
|
|
|
var ids = [];
|
|
|
|
var ii;
|
|
|
|
|
|
|
|
// Show any hidden inline comment rows directly below this one.
|
|
|
|
while (next && JX.Stratcom.hasSigil(next, 'inline-row')) {
|
|
|
|
JX.DOM.show(next);
|
|
|
|
|
|
|
|
var comments = JX.DOM.scry(next, 'div', 'differential-inline-comment');
|
|
|
|
for (ii = 0; ii < comments.length; ii++) {
|
|
|
|
var id = JX.Stratcom.getData(comments[ii]).id;
|
|
|
|
if (id) {
|
|
|
|
ids.push(id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
next = next.nextSibling;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Remove any "reveal" icons on the row.
|
|
|
|
var reveals = JX.DOM.scry(row, 'a', 'reveal-inlines');
|
|
|
|
for (ii = 0; ii < reveals.length; ii++) {
|
|
|
|
JX.DOM.remove(reveals[ii]);
|
|
|
|
}
|
|
|
|
|
|
|
|
new JX.Workflow(config.uri, {op: 'show', ids: ids.join(',')})
|
|
|
|
.setHandler(JX.bag)
|
|
|
|
.start();
|
|
|
|
});
|
|
|
|
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
});
|