2011-01-25 20:31:40 +01:00
|
|
|
/**
|
|
|
|
|
* @provides differential-changeset-view-css
|
2015-03-28 00:00:09 +01:00
|
|
|
* @requires phui-inline-comment-view-css
|
2011-01-25 20:31:40 +01:00
|
|
|
*/
|
|
|
|
|
|
2011-06-10 17:34:17 +02:00
|
|
|
.differential-changeset {
|
|
|
|
|
position: relative;
|
2012-12-13 06:00:35 +01:00
|
|
|
margin: 0;
|
2016-03-12 22:02:32 +01:00
|
|
|
padding-top: 16px;
|
2013-12-30 22:22:00 +01:00
|
|
|
overflow-x: auto;
|
2015-03-30 21:06:40 +02:00
|
|
|
|
|
|
|
|
/* Fixes what seems to be a layout bug in Firefox which causes scrollbars,
|
|
|
|
|
to appear unpredictably, see discussion in T7690. */
|
|
|
|
|
overflow-y: hidden;
|
2011-06-10 17:34:17 +02:00
|
|
|
}
|
|
|
|
|
|
2014-04-03 06:49:28 +02:00
|
|
|
.device-phone .differential-changeset {
|
|
|
|
|
overflow-x: scroll;
|
2014-04-04 03:02:55 +02:00
|
|
|
-webkit-overflow-scrolling: touch;
|
2014-04-03 06:49:28 +02:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.differential-diff {
|
2017-07-19 23:38:55 +02:00
|
|
|
background: {$diff.background};
|
2013-09-29 00:55:38 +02:00
|
|
|
width: 100%;
|
2013-10-14 22:12:36 +02:00
|
|
|
border-top: 1px solid {$lightblueborder};
|
|
|
|
|
border-bottom: 1px solid {$lightblueborder};
|
Break long words in differential two-up view
Summary: This should prevent long lines from making the code width different between files, which can be annoying. (And of course, it stops long lines from making a giant scrollbar too.)
Test Plan:
Loaded this diff in Chrome, Firefox, IE9, and IE8:
{F137505}
(That's a screenshot from Chrome, but it looks about the same in the other browsers.)
Reviewers: chad, #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin, chad
Maniphest Tasks: T2004
Differential Revision: https://secure.phabricator.com/D8686
2014-04-03 18:37:49 +02:00
|
|
|
table-layout: fixed;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-05 23:01:52 +01:00
|
|
|
.differential-diff.diff-2up {
|
|
|
|
|
min-width: 780px;
|
|
|
|
|
}
|
|
|
|
|
|
Break long words in differential two-up view
Summary: This should prevent long lines from making the code width different between files, which can be annoying. (And of course, it stops long lines from making a giant scrollbar too.)
Test Plan:
Loaded this diff in Chrome, Firefox, IE9, and IE8:
{F137505}
(That's a screenshot from Chrome, but it looks about the same in the other browsers.)
Reviewers: chad, #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin, chad
Maniphest Tasks: T2004
Differential Revision: https://secure.phabricator.com/D8686
2014-04-03 18:37:49 +02:00
|
|
|
.differential-diff col.num {
|
|
|
|
|
width: 45px;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-05 23:01:52 +01:00
|
|
|
.device .differential-diff.diff-1up col.num {
|
|
|
|
|
width: 32px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff.diff-2up col.left,
|
|
|
|
|
.differential-diff.diff-2up col.right {
|
Break long words in differential two-up view
Summary: This should prevent long lines from making the code width different between files, which can be annoying. (And of course, it stops long lines from making a giant scrollbar too.)
Test Plan:
Loaded this diff in Chrome, Firefox, IE9, and IE8:
{F137505}
(That's a screenshot from Chrome, but it looks about the same in the other browsers.)
Reviewers: chad, #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin, chad
Maniphest Tasks: T2004
Differential Revision: https://secure.phabricator.com/D8686
2014-04-03 18:37:49 +02:00
|
|
|
width: 49.25%;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-05 23:11:36 +01:00
|
|
|
.differential-diff.diff-1up col.unified {
|
|
|
|
|
width: 99.5%;
|
|
|
|
|
}
|
|
|
|
|
|
Break long words in differential two-up view
Summary: This should prevent long lines from making the code width different between files, which can be annoying. (And of course, it stops long lines from making a giant scrollbar too.)
Test Plan:
Loaded this diff in Chrome, Firefox, IE9, and IE8:
{F137505}
(That's a screenshot from Chrome, but it looks about the same in the other browsers.)
Reviewers: chad, #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, Korvin, chad
Maniphest Tasks: T2004
Differential Revision: https://secure.phabricator.com/D8686
2014-04-03 18:37:49 +02:00
|
|
|
.differential-diff col.copy {
|
|
|
|
|
width: 0.5%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff col.cov {
|
|
|
|
|
width: 1%;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td {
|
2015-03-28 00:00:09 +01:00
|
|
|
vertical-align: top;
|
|
|
|
|
white-space: pre-wrap;
|
|
|
|
|
word-wrap: break-word;
|
2016-05-16 18:57:33 +02:00
|
|
|
padding: 1px 8px;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2015-03-05 23:01:52 +01:00
|
|
|
.device .differential-diff td {
|
2016-05-16 18:57:33 +02:00
|
|
|
padding: 1px 4px;
|
2015-03-05 23:01:52 +01:00
|
|
|
}
|
|
|
|
|
|
2016-06-06 22:59:03 +02:00
|
|
|
.prose-diff {
|
2016-11-07 20:19:08 +01:00
|
|
|
padding: 12px 0;
|
2016-06-06 22:59:03 +02:00
|
|
|
white-space: pre-wrap;
|
2016-06-10 17:13:56 +02:00
|
|
|
color: {$greytext};
|
2016-06-06 22:59:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prose-diff-frame {
|
|
|
|
|
padding: 12px;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-06 17:16:34 +02:00
|
|
|
.prose-diff span.old,
|
|
|
|
|
.prose-diff span.new {
|
|
|
|
|
padding: 0 2px;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-04 20:14:20 +01:00
|
|
|
.prose-diff span.old,
|
2016-06-06 17:16:34 +02:00
|
|
|
.prose-diff span.new {
|
2017-01-04 20:14:20 +01:00
|
|
|
color: {$darkgreytext};
|
2016-06-06 17:16:34 +02:00
|
|
|
}
|
|
|
|
|
|
2019-02-17 16:58:26 +01:00
|
|
|
.differential-changeset-immutable .differential-diff td {
|
2012-04-11 00:00:09 +02:00
|
|
|
cursor: auto;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-10 22:13:47 +01:00
|
|
|
.differential-diff td.old {
|
2017-01-10 23:45:58 +01:00
|
|
|
background: {$old-background};
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2017-01-10 22:13:47 +01:00
|
|
|
.differential-diff td.new {
|
2017-01-10 23:45:58 +01:00
|
|
|
background: {$new-background};
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2012-06-15 09:53:26 +02:00
|
|
|
.differential-diff td.old-rebase {
|
|
|
|
|
background: #ffeeee;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td.new-rebase {
|
|
|
|
|
background: #eeffee;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-06 17:16:34 +02:00
|
|
|
.differential-diff td.old span.bright,
|
2017-01-10 22:13:47 +01:00
|
|
|
.differential-diff td.old-full,
|
2016-06-06 17:16:34 +02:00
|
|
|
.prose-diff span.old {
|
2017-01-10 23:45:58 +01:00
|
|
|
background: {$old-bright};
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 17:10:56 +01:00
|
|
|
|
2016-06-06 17:16:34 +02:00
|
|
|
.differential-diff td.new span.bright,
|
2017-01-10 22:13:47 +01:00
|
|
|
.differential-diff td.new-full,
|
2016-06-06 17:16:34 +02:00
|
|
|
.prose-diff span.new {
|
2017-01-10 23:45:58 +01:00
|
|
|
background: {$new-bright};
|
2012-04-30 06:35:43 +02:00
|
|
|
}
|
|
|
|
|
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 17:10:56 +01:00
|
|
|
.differential-diff td span.depth-out,
|
|
|
|
|
.differential-diff td span.depth-in {
|
|
|
|
|
padding: 2px 0;
|
|
|
|
|
background-size: 12px 12px;
|
|
|
|
|
background-repeat: no-repeat;
|
|
|
|
|
background-position: left center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td span.depth-out {
|
|
|
|
|
background-image: url(/rsrc/image/chevron-out.png);
|
2019-02-19 23:39:08 +01:00
|
|
|
background-color: {$old-bright};
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 17:10:56 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td span.depth-in {
|
2019-02-19 23:39:08 +01:00
|
|
|
background-position: 1px center;
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 17:10:56 +01:00
|
|
|
background-image: url(/rsrc/image/chevron-in.png);
|
2019-02-19 23:39:08 +01:00
|
|
|
background-color: {$new-bright};
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 17:10:56 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2012-05-05 02:41:06 +02:00
|
|
|
.differential-diff td.copy {
|
2012-12-07 21:37:11 +01:00
|
|
|
min-width: 0.5%;
|
|
|
|
|
width: 0.5%;
|
2012-05-05 02:41:06 +02:00
|
|
|
padding: 0;
|
In Differential, give the "moved/copied from" gutter a more clear visual look
Summary:
Depends on D20196. See PHI985. When empty, the "moved/copied" gutter currently renders with the same background color as the rest of the line. This can be misleading because it makes code look more indented than it is, especially if you're unfamiliar with the tool:
{F6225179}
If we remove this misleading coloration, we get a white gap. This is more clear, but looks a little odd:
{F6225181}
Instead, give this gutter a subtle background fill in all casses, to make it more clear that it's a separate gutter region, not a part of the text diff:
{F6225183}
Test Plan: See screenshots. Copied text from a diff, added/removed inlines, etc.
Reviewers: amckinley
Reviewed By: amckinley
Differential Revision: https://secure.phabricator.com/D20197
2019-02-20 13:40:06 +01:00
|
|
|
background: {$lightbluebackground};
|
2012-05-05 02:41:06 +02:00
|
|
|
}
|
|
|
|
|
|
2012-05-05 02:41:06 +02:00
|
|
|
.differential-diff td.new-copy,
|
|
|
|
|
.differential-diff td.new-copy span.bright {
|
2017-01-10 23:45:58 +01:00
|
|
|
background: {$copy-background};
|
2012-05-05 02:41:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td.new-move,
|
|
|
|
|
.differential-diff td.new-move span.bright {
|
2017-01-10 23:45:58 +01:00
|
|
|
background: {$move-background};
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2012-03-15 00:45:40 +01:00
|
|
|
.differential-diff td.comment {
|
|
|
|
|
background: #dddddd;
|
|
|
|
|
}
|
|
|
|
|
|
Use `<td class="n" data-n="3">` instead of `<th>3</th>` for line numbers
Summary:
Ref T13161. Ref T12822. See PHI870. Long ago, the web was simple. You could leave your doors unlocked, you knew all your neighbors, crime hadn't been invented yet, and `<th>3</th>` was a perfectly fine way to render a line number cell containing the number "3".
But times have changed!
- In PHI870, this isn't good for screenreaders. We can't do much about this, so switch to `<td>`.
- In D19349 / T13105 and elsewhere, this `::after { content: attr(data-n); }` approach seems like the least bad general-purpose approach for preventing line numbers from being copied. Although Differential needs even more magic beyond this in the two-up view, this is likely good enough for the one-up view, and is consistent with other views (paste, harbormaster logs, general source display) where this technique is sufficient on its own.
The chance this breaks //something// is pretty much 100%, but we've got a week to figure out what it breaks. I couldn't find any issues immediately.
Test Plan:
- Created, edited, deleted inlines in 1-up and 2-up views.
- Replied, keyboard-navigated, keyboard-replied, drag-selected, poked and prodded everything.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20188
2019-02-16 18:50:20 +01:00
|
|
|
.differential-diff .inline > td {
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Specify line number behaviors after other behaviors because line numbers
|
|
|
|
|
should always have a boring grey background. */
|
|
|
|
|
|
|
|
|
|
.differential-diff td.n {
|
|
|
|
|
text-align: right;
|
|
|
|
|
padding: 1px 6px 1px 0;
|
|
|
|
|
vertical-align: top;
|
|
|
|
|
background: {$lightbluebackground};
|
|
|
|
|
color: {$bluetext};
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
border-right: 1px solid {$thinblueborder};
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
}
|
|
|
|
|
|
In Differential, give the "moved/copied from" gutter a more clear visual look
Summary:
Depends on D20196. See PHI985. When empty, the "moved/copied" gutter currently renders with the same background color as the rest of the line. This can be misleading because it makes code look more indented than it is, especially if you're unfamiliar with the tool:
{F6225179}
If we remove this misleading coloration, we get a white gap. This is more clear, but looks a little odd:
{F6225181}
Instead, give this gutter a subtle background fill in all casses, to make it more clear that it's a separate gutter region, not a part of the text diff:
{F6225183}
Test Plan: See screenshots. Copied text from a diff, added/removed inlines, etc.
Reviewers: amckinley
Reviewed By: amckinley
Differential Revision: https://secure.phabricator.com/D20197
2019-02-20 13:40:06 +01:00
|
|
|
.differential-diff td + td.n {
|
|
|
|
|
border-left: 1px solid {$thinblueborder};
|
|
|
|
|
}
|
|
|
|
|
|
Use `<td class="n" data-n="3">` instead of `<th>3</th>` for line numbers
Summary:
Ref T13161. Ref T12822. See PHI870. Long ago, the web was simple. You could leave your doors unlocked, you knew all your neighbors, crime hadn't been invented yet, and `<th>3</th>` was a perfectly fine way to render a line number cell containing the number "3".
But times have changed!
- In PHI870, this isn't good for screenreaders. We can't do much about this, so switch to `<td>`.
- In D19349 / T13105 and elsewhere, this `::after { content: attr(data-n); }` approach seems like the least bad general-purpose approach for preventing line numbers from being copied. Although Differential needs even more magic beyond this in the two-up view, this is likely good enough for the one-up view, and is consistent with other views (paste, harbormaster logs, general source display) where this technique is sufficient on its own.
The chance this breaks //something// is pretty much 100%, but we've got a week to figure out what it breaks. I couldn't find any issues immediately.
Test Plan:
- Created, edited, deleted inlines in 1-up and 2-up views.
- Replied, keyboard-navigated, keyboard-replied, drag-selected, poked and prodded everything.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20188
2019-02-16 18:50:20 +01:00
|
|
|
.differential-diff td.n::before {
|
|
|
|
|
content: attr(data-n);
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-17 16:58:26 +01:00
|
|
|
.differential-diff td.show-context-line.n {
|
|
|
|
|
cursor: auto;
|
|
|
|
|
}
|
|
|
|
|
|
Show coverage information in Differential
Summary:
Render coverage information in the right gutter, if available.
We could render some kind of summary report deal too but this seems like a good
start.
Test Plan:
- Looked at diffs with coverage.
- Looked at diffs without coverage.
- Used inline comments, diff-of-diff, "show more", "show entire file", "show
generated file", "undo". Nothing seemed disrupted by the addition of a 5th
column.
Reviewers: btrahan, tuomaspelkonen, jungejason
Reviewed By: btrahan
CC: zeeg, aran, epriestley
Maniphest Tasks: T140
Differential Revision: https://secure.phabricator.com/D1527
2012-01-31 21:07:47 +01:00
|
|
|
.differential-diff td.cov {
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
td.cov-U {
|
2012-03-13 04:04:12 +01:00
|
|
|
background: #dd8866;
|
Show coverage information in Differential
Summary:
Render coverage information in the right gutter, if available.
We could render some kind of summary report deal too but this seems like a good
start.
Test Plan:
- Looked at diffs with coverage.
- Looked at diffs without coverage.
- Used inline comments, diff-of-diff, "show more", "show entire file", "show
generated file", "undo". Nothing seemed disrupted by the addition of a 5th
column.
Reviewers: btrahan, tuomaspelkonen, jungejason
Reviewed By: btrahan
CC: zeeg, aran, epriestley
Maniphest Tasks: T140
Differential Revision: https://secure.phabricator.com/D1527
2012-01-31 21:07:47 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
td.cov-C {
|
2012-03-13 04:04:12 +01:00
|
|
|
background: #66bbff;
|
Show coverage information in Differential
Summary:
Render coverage information in the right gutter, if available.
We could render some kind of summary report deal too but this seems like a good
start.
Test Plan:
- Looked at diffs with coverage.
- Looked at diffs without coverage.
- Used inline comments, diff-of-diff, "show more", "show entire file", "show
generated file", "undo". Nothing seemed disrupted by the addition of a 5th
column.
Reviewers: btrahan, tuomaspelkonen, jungejason
Reviewed By: btrahan
CC: zeeg, aran, epriestley
Maniphest Tasks: T140
Differential Revision: https://secure.phabricator.com/D1527
2012-01-31 21:07:47 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
td.cov-N {
|
|
|
|
|
background: #ddeeff;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
td.cov-X {
|
|
|
|
|
background: #aa00aa;
|
|
|
|
|
}
|
|
|
|
|
|
Provide a rough, unstable API for reporting coverage into Diffusion
Summary:
Ref T4994. This stuff works:
- You can dump a blob of coverage information into `diffusion.updatecoverage`. This wipes existing coverage information and replaces it.
- It shows up when viewing files.
- It shows up when viewing commits.
This stuff does not work:
- When viewing files, the Javascript hover interaction isn't tied in yet.
- We always show this information, even if you're behind the commit where it was generated.
- You can't do incremental updates.
- There's no aggregation at the file (this file has 90% coverage), diff (the changes in this commit are 90% covered), or directory (the code in this directory has 90% coverage) levels yet.
- This is probably not the final form of the UI, storage, or API, so you should expect occasional changes over time. I've marked the method as "Unstable" for now.
Test Plan:
- Ran `save_lint.php` to check for collateral damage; it worked fine.
- Ran `save_lint.php` on a new branch to check creation.
- Published some fake coverage information.
- Viewed an affected commit.
- Viewed an affected file.
{F151915}
{F151916}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: jhurwitz, epriestley, zeeg
Maniphest Tasks: T5044, T4994
Differential Revision: https://secure.phabricator.com/D9022
2014-05-18 01:10:54 +02:00
|
|
|
td.cov-I {
|
|
|
|
|
background: {$lightgreybackground};
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-05 01:47:39 +02:00
|
|
|
.differential-diff td.source-cov-C,
|
|
|
|
|
.differential-diff td.source-cov-C span.bright {
|
2012-03-13 04:04:12 +01:00
|
|
|
background: #cceeff;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-05 01:47:39 +02:00
|
|
|
.differential-diff td.source-cov-U,
|
|
|
|
|
.differential-diff td.source-cov-U span.bright {
|
2012-03-13 04:04:12 +01:00
|
|
|
background: #ffbb99;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-05 01:47:39 +02:00
|
|
|
.differential-diff td.source-cov-N,
|
|
|
|
|
.differential-diff td.source-cov-N span.bright {
|
2012-03-13 04:04:12 +01:00
|
|
|
background: #f3f6ff;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.differential-diff td.show-more,
|
2019-02-17 16:58:26 +01:00
|
|
|
.differential-diff td.show-context-line,
|
2012-08-30 01:34:52 +02:00
|
|
|
.differential-diff td.show-context,
|
2011-01-25 20:31:40 +01:00
|
|
|
.differential-diff td.differential-shield {
|
2013-10-14 22:12:36 +02:00
|
|
|
background: {$lightbluebackground};
|
2013-09-29 00:55:38 +02:00
|
|
|
padding: 12px 0;
|
2013-10-14 22:12:36 +02:00
|
|
|
border-top: 1px solid {$thinblueborder};
|
|
|
|
|
border-bottom: 1px solid {$thinblueborder};
|
2012-08-30 01:34:52 +02:00
|
|
|
}
|
|
|
|
|
|
2015-03-05 23:01:52 +01:00
|
|
|
.device .differential-diff td.show-more,
|
2019-02-17 16:58:26 +01:00
|
|
|
.device .differential-diff td.show-context-line,
|
2015-03-05 23:01:52 +01:00
|
|
|
.device .differential-diff td.show-context,
|
|
|
|
|
.device .differential-diff td.differential-shield {
|
|
|
|
|
padding: 6px 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-30 01:34:52 +02:00
|
|
|
.differential-diff td.show-more,
|
|
|
|
|
.differential-diff td.differential-shield {
|
2015-02-26 18:26:36 +01:00
|
|
|
font: {$basefont};
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$smallerfontsize};
|
2011-01-25 20:31:40 +01:00
|
|
|
white-space: normal;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td.show-more {
|
2012-08-30 01:34:52 +02:00
|
|
|
text-align: center;
|
2013-10-14 22:12:36 +02:00
|
|
|
color: {$bluetext};
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2019-02-17 16:58:26 +01:00
|
|
|
.differential-diff td.show-context-line {
|
2012-08-30 01:34:52 +02:00
|
|
|
padding-right: 6px;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-17 16:58:26 +01:00
|
|
|
.differential-diff td.show-context-line.left-context {
|
|
|
|
|
border-right: none;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-30 01:34:52 +02:00
|
|
|
.differential-diff td.show-context {
|
2012-12-06 20:33:04 +01:00
|
|
|
padding-left: 14px;
|
2012-08-30 01:34:52 +02:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.differential-diff td.differential-shield {
|
2012-08-30 01:34:52 +02:00
|
|
|
text-align: center;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff td.differential-shield a {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-14 02:21:16 +02:00
|
|
|
.differential-diff .differential-image-diff {
|
|
|
|
|
background-image: url(/rsrc/image/checker_light.png);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff .differential-image-diff:hover {
|
|
|
|
|
background-image: url(/rsrc/image/checker_dark.png);
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-19 23:46:37 +02:00
|
|
|
.differential-diff .differential-image-diff td {
|
|
|
|
|
padding: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-image-stage {
|
2014-08-20 00:48:30 +02:00
|
|
|
overflow: auto;
|
2014-08-19 23:46:37 +02:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.differential-meta-notice {
|
2017-07-19 23:38:55 +02:00
|
|
|
border-top: 1px solid {$gentle.highlight.border};
|
|
|
|
|
border-bottom: 1px solid {$gentle.highlight.border};
|
|
|
|
|
background-color: {$gentle.highlight};
|
2013-10-14 22:12:36 +02:00
|
|
|
padding: 12px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-meta-notice + .differential-diff {
|
|
|
|
|
border-top: none;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
2011-01-26 00:19:06 +01:00
|
|
|
|
|
|
|
|
.differential-changeset h1 {
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$biggestfontsize};
|
2016-03-12 22:02:32 +01:00
|
|
|
padding: 2px 0 20px 12px;
|
2015-06-25 16:53:55 +02:00
|
|
|
line-height: 20px;
|
2017-07-17 20:08:17 +02:00
|
|
|
color: {$blacktext};
|
2014-04-03 06:49:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-phone .differential-changeset h1 {
|
|
|
|
|
word-break: break-word;
|
|
|
|
|
margin-right: 8px;
|
2011-01-26 00:19:06 +01:00
|
|
|
}
|
|
|
|
|
|
2011-02-02 00:52:04 +01:00
|
|
|
.differential-reticle {
|
2015-03-28 00:00:09 +01:00
|
|
|
background-color: {$sh-yellowbackground};
|
|
|
|
|
border: 1px solid {$sh-yellowborder};
|
2013-10-14 22:12:36 +02:00
|
|
|
position: absolute;
|
|
|
|
|
opacity: 0.5;
|
2015-03-28 00:00:09 +01:00
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
2015-03-07 20:47:55 +01:00
|
|
|
box-sizing: border-box;
|
2017-05-16 23:53:21 +02:00
|
|
|
pointer-events: none;
|
2011-02-02 00:52:04 +01:00
|
|
|
}
|
|
|
|
|
|
2015-03-28 00:00:09 +01:00
|
|
|
.differential-loading {
|
2017-07-19 23:38:55 +02:00
|
|
|
border-top: 1px solid {$gentle.highlight.border};
|
|
|
|
|
border-bottom: 1px solid {$gentle.highlight.border};
|
|
|
|
|
background-color: {$gentle.highlight};
|
2015-03-28 00:00:09 +01:00
|
|
|
padding: 12px;
|
|
|
|
|
text-align: center;
|
2011-06-14 21:42:27 +02:00
|
|
|
}
|
|
|
|
|
|
2015-03-28 00:00:09 +01:00
|
|
|
.differential-collapse-undo {
|
|
|
|
|
color: {$darkbluetext};
|
|
|
|
|
padding: 12px;
|
2013-10-14 22:12:36 +02:00
|
|
|
border: 1px solid {$blue};
|
2015-03-28 00:00:09 +01:00
|
|
|
text-align: center;
|
|
|
|
|
background-color: {$lightblue};
|
2017-05-17 21:51:29 +02:00
|
|
|
margin: 8px;
|
2012-01-04 18:10:37 +01:00
|
|
|
}
|
|
|
|
|
|
2015-03-28 00:00:09 +01:00
|
|
|
.differential-collapse-undo a {
|
|
|
|
|
font-weight: bold;
|
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
|
|
|
}
|
|
|
|
|
|
2015-03-28 00:00:09 +01:00
|
|
|
.differential-file-icon-header .phui-icon-view {
|
|
|
|
|
display: inline-block;
|
|
|
|
|
margin: 0 6px 2px 0;
|
|
|
|
|
vertical-align: middle;
|
|
|
|
|
font-size: 14px;
|
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
|
|
|
}
|
|
|
|
|
|
2015-03-28 00:00:09 +01:00
|
|
|
.device-phone .differential-file-icon-header .phui-icon-view {
|
|
|
|
|
display: none;
|
2011-02-05 02:53:14 +01:00
|
|
|
}
|
2011-05-06 21:58:53 +02:00
|
|
|
|
|
|
|
|
.differential-changeset-buttons {
|
|
|
|
|
float: right;
|
2016-03-12 22:02:32 +01:00
|
|
|
margin-right: 12px;
|
2011-05-06 21:58:53 +02:00
|
|
|
}
|
|
|
|
|
|
2016-07-09 22:53:57 +02:00
|
|
|
.device-phone .differential-changeset-buttons .button .phui-button-text {
|
|
|
|
|
visibility: hidden;
|
|
|
|
|
width: 0;
|
2011-05-06 21:58:53 +02:00
|
|
|
margin-left: 8px;
|
|
|
|
|
}
|
2011-06-08 03:59:42 +02:00
|
|
|
|
|
|
|
|
.differential-property-table {
|
2014-08-19 23:46:37 +02:00
|
|
|
margin: 12px;
|
|
|
|
|
background: {$lightgreybackground};
|
|
|
|
|
border: 1px solid {$lightblueborder};
|
|
|
|
|
border-bottom: 1px solid {$blueborder};
|
2011-06-08 03:59:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-property-table td em {
|
2013-09-02 17:12:18 +02:00
|
|
|
color: {$lightgreytext};
|
2011-06-08 03:59:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-property-table td.oval {
|
|
|
|
|
background: #ffd0d0;
|
2014-08-19 23:46:37 +02:00
|
|
|
width: 50%;
|
2011-06-08 03:59:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-property-table td.nval {
|
|
|
|
|
background: #d0ffd0;
|
2014-08-19 23:46:37 +02:00
|
|
|
width: 50%;
|
2011-06-08 03:59:42 +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
|
|
|
|
2012-02-29 23:28:48 +01:00
|
|
|
tr.differential-inline-hidden {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tr.differential-inline-loading {
|
|
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
2016-03-12 22:02:32 +01:00
|
|
|
|
|
|
|
|
.differential-review-stage {
|
|
|
|
|
position: relative;
|
|
|
|
|
}
|
Restore the "buoyant" header in Differential
Summary:
Fixes T1591. This was removed long ago because it was a mess to implement and caused a bunch of weird issues, and also my tolerance for dealing with weird JS issues was much, much lower.
I have now survived the fires of JX.Scrollbar and would love to address 200 small nitpicks about obscure browser behaviors on Linux, so open the floodgates again.
A secondary goal here is to create room to add a global view state menu on the right, with 300 options like "hide all inlines", "hide done inlines", "hide collapsed inlines", "hide ghosts", "show ghosts", "enable filetree", "disable filetree", etc, etc. Not sure how much of this I'll actually do. I have one more experiment I want to try first.
Test Plan: {F4963294}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T1591
Differential Revision: https://secure.phabricator.com/D17945
2017-05-17 23:49:26 +02:00
|
|
|
|
|
|
|
|
.diff-banner {
|
|
|
|
|
position: fixed;
|
|
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
|
|
|
|
right: 0;
|
2017-07-17 20:08:17 +02:00
|
|
|
background: {$page.content};
|
Restore the "buoyant" header in Differential
Summary:
Fixes T1591. This was removed long ago because it was a mess to implement and caused a bunch of weird issues, and also my tolerance for dealing with weird JS issues was much, much lower.
I have now survived the fires of JX.Scrollbar and would love to address 200 small nitpicks about obscure browser behaviors on Linux, so open the floodgates again.
A secondary goal here is to create room to add a global view state menu on the right, with 300 options like "hide all inlines", "hide done inlines", "hide collapsed inlines", "hide ghosts", "show ghosts", "enable filetree", "disable filetree", etc, etc. Not sure how much of this I'll actually do. I have one more experiment I want to try first.
Test Plan: {F4963294}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T1591
Differential Revision: https://secure.phabricator.com/D17945
2017-05-17 23:49:26 +02:00
|
|
|
box-shadow: 0px 1px 3px rgba(0, 0, 0, 0.1);
|
|
|
|
|
border-bottom: 1px solid {$lightgreyborder};
|
2017-06-10 00:17:36 +02:00
|
|
|
padding: 8px 18px;
|
Restore the "buoyant" header in Differential
Summary:
Fixes T1591. This was removed long ago because it was a mess to implement and caused a bunch of weird issues, and also my tolerance for dealing with weird JS issues was much, much lower.
I have now survived the fires of JX.Scrollbar and would love to address 200 small nitpicks about obscure browser behaviors on Linux, so open the floodgates again.
A secondary goal here is to create room to add a global view state menu on the right, with 300 options like "hide all inlines", "hide done inlines", "hide collapsed inlines", "hide ghosts", "show ghosts", "enable filetree", "disable filetree", etc, etc. Not sure how much of this I'll actually do. I have one more experiment I want to try first.
Test Plan: {F4963294}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T1591
Differential Revision: https://secure.phabricator.com/D17945
2017-05-17 23:49:26 +02:00
|
|
|
vertical-align: middle;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
font-size: {$biggerfontsize};
|
2017-06-10 00:17:36 +02:00
|
|
|
line-height: 28px;
|
Restore the "buoyant" header in Differential
Summary:
Fixes T1591. This was removed long ago because it was a mess to implement and caused a bunch of weird issues, and also my tolerance for dealing with weird JS issues was much, much lower.
I have now survived the fires of JX.Scrollbar and would love to address 200 small nitpicks about obscure browser behaviors on Linux, so open the floodgates again.
A secondary goal here is to create room to add a global view state menu on the right, with 300 options like "hide all inlines", "hide done inlines", "hide collapsed inlines", "hide ghosts", "show ghosts", "enable filetree", "disable filetree", etc, etc. Not sure how much of this I'll actually do. I have one more experiment I want to try first.
Test Plan: {F4963294}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T1591
Differential Revision: https://secure.phabricator.com/D17945
2017-05-17 23:49:26 +02:00
|
|
|
}
|
|
|
|
|
|
2017-05-19 01:31:16 +02:00
|
|
|
.diff-banner-path {
|
|
|
|
|
color: {$greytext};
|
|
|
|
|
}
|
2017-05-30 23:00:02 +02:00
|
|
|
|
2017-06-10 00:17:36 +02:00
|
|
|
.diff-banner-buttons .button {
|
|
|
|
|
margin-left: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-30 23:00:02 +02:00
|
|
|
.diff-banner-has-unsaved,
|
2017-06-15 13:28:21 +02:00
|
|
|
.diff-banner-has-unsubmitted,
|
|
|
|
|
.diff-banner-has-draft-done {
|
2017-07-19 23:38:55 +02:00
|
|
|
background: {$gentle.highlight};
|
2017-05-30 23:00:02 +02:00
|
|
|
}
|
2017-06-03 15:21:45 +02:00
|
|
|
|
|
|
|
|
.diff-banner-buttons {
|
|
|
|
|
float: right;
|
|
|
|
|
}
|
Behold! Copy text from either side of a diff!
Summary:
Ref T12822. Ref T13161. By default, when users select text from a diff and copy it to the clipboard, they get both sides of the diff and all the line numbers. This is usually not what they intended to copy.
As of D20188, we use `content: attr(...)` to render line numbers. No browser copies this text, so that fixes line numbers.
We can use "user-select" CSS to visually prevent selection of line numbers and other stuff we don't want to copy. In Firefox and Chrome, "user-select" also applies to copied text, so getting "user-select" on the right nodes is largely good enough to do what we want.
In Safari, "user-select" is only visual, so we always need to crawl the DOM to figure out what text to pull out of it anyway.
In all browsers, we likely want to crawl the DOM anyway because this will let us show one piece of text and copy a different piece of text. We probably want to do this in the future to preserve "\t" tabs, and possibly to let us render certain character codes in one way but copy their original values. For example, we could render "\x07" as "␇".
Finally, we have to figure out which side of the diff we're copying from. The rule here is:
- If you start the selection by clicking somewhere on the left or right side of the diff, that's what you're copying.
- Otherwise, use normal document copy rules.
So the overall flow here is:
- Listen for clicks.
- When the user clicks the left or right side of the diff, store what they clicked.
- When a selection starts, and something is actually selected, check if it was initiated by clicking a diff. If it was, apply a visual effect to get "user-select" where it needs to go and show the user what we think they're doing and what we're going to copy.
- (Then, try to handle a bunch of degenerate cases where you start a selection and then click inside that selection.)
- When a user clicks elsewhere or ends the selection with nothing selected, clear the selection mode.
- When a user copies text, if we have an active selection mode, pull all the selected nodes out of the DOM and filter out the ones we don't want to copy, then stitch the text back together. Although I believe this didn't work well in ~2010, it appears to work well today.
Test Plan: This mostly seems to work in Safari, Chrome, and Firefox. T12822 has some errata. I haven't tested touch events but am satisfied if the touch event story is anything better than "permanently destroys data".
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20191
2019-02-16 18:32:13 +01:00
|
|
|
|
|
|
|
|
/* In Firefox, making the table unselectable and then making cells selectable
|
|
|
|
|
does not work: the cells remain unselectable. Narrowly mark the cells as
|
|
|
|
|
unselectable. */
|
|
|
|
|
|
|
|
|
|
.differential-diff.copy-l > tbody > tr > td,
|
|
|
|
|
.differential-diff.copy-r > tbody > tr > td {
|
2019-02-17 16:58:26 +01:00
|
|
|
-moz-user-select: none;
|
Behold! Copy text from either side of a diff!
Summary:
Ref T12822. Ref T13161. By default, when users select text from a diff and copy it to the clipboard, they get both sides of the diff and all the line numbers. This is usually not what they intended to copy.
As of D20188, we use `content: attr(...)` to render line numbers. No browser copies this text, so that fixes line numbers.
We can use "user-select" CSS to visually prevent selection of line numbers and other stuff we don't want to copy. In Firefox and Chrome, "user-select" also applies to copied text, so getting "user-select" on the right nodes is largely good enough to do what we want.
In Safari, "user-select" is only visual, so we always need to crawl the DOM to figure out what text to pull out of it anyway.
In all browsers, we likely want to crawl the DOM anyway because this will let us show one piece of text and copy a different piece of text. We probably want to do this in the future to preserve "\t" tabs, and possibly to let us render certain character codes in one way but copy their original values. For example, we could render "\x07" as "␇".
Finally, we have to figure out which side of the diff we're copying from. The rule here is:
- If you start the selection by clicking somewhere on the left or right side of the diff, that's what you're copying.
- Otherwise, use normal document copy rules.
So the overall flow here is:
- Listen for clicks.
- When the user clicks the left or right side of the diff, store what they clicked.
- When a selection starts, and something is actually selected, check if it was initiated by clicking a diff. If it was, apply a visual effect to get "user-select" where it needs to go and show the user what we think they're doing and what we're going to copy.
- (Then, try to handle a bunch of degenerate cases where you start a selection and then click inside that selection.)
- When a user clicks elsewhere or ends the selection with nothing selected, clear the selection mode.
- When a user copies text, if we have an active selection mode, pull all the selected nodes out of the DOM and filter out the ones we don't want to copy, then stitch the text back together. Although I believe this didn't work well in ~2010, it appears to work well today.
Test Plan: This mostly seems to work in Safari, Chrome, and Firefox. T12822 has some errata. I haven't tested touch events but am satisfied if the touch event story is anything better than "permanently destroys data".
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20191
2019-02-16 18:32:13 +01:00
|
|
|
-ms-user-select: none;
|
|
|
|
|
-webkit-user-select: none;
|
|
|
|
|
user-select: none;
|
|
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.differential-diff.copy-l > tbody > tr > td:nth-child(2) {
|
2019-02-17 16:58:26 +01:00
|
|
|
-moz-user-select: auto;
|
|
|
|
|
-ms-user-select: auto;
|
Behold! Copy text from either side of a diff!
Summary:
Ref T12822. Ref T13161. By default, when users select text from a diff and copy it to the clipboard, they get both sides of the diff and all the line numbers. This is usually not what they intended to copy.
As of D20188, we use `content: attr(...)` to render line numbers. No browser copies this text, so that fixes line numbers.
We can use "user-select" CSS to visually prevent selection of line numbers and other stuff we don't want to copy. In Firefox and Chrome, "user-select" also applies to copied text, so getting "user-select" on the right nodes is largely good enough to do what we want.
In Safari, "user-select" is only visual, so we always need to crawl the DOM to figure out what text to pull out of it anyway.
In all browsers, we likely want to crawl the DOM anyway because this will let us show one piece of text and copy a different piece of text. We probably want to do this in the future to preserve "\t" tabs, and possibly to let us render certain character codes in one way but copy their original values. For example, we could render "\x07" as "␇".
Finally, we have to figure out which side of the diff we're copying from. The rule here is:
- If you start the selection by clicking somewhere on the left or right side of the diff, that's what you're copying.
- Otherwise, use normal document copy rules.
So the overall flow here is:
- Listen for clicks.
- When the user clicks the left or right side of the diff, store what they clicked.
- When a selection starts, and something is actually selected, check if it was initiated by clicking a diff. If it was, apply a visual effect to get "user-select" where it needs to go and show the user what we think they're doing and what we're going to copy.
- (Then, try to handle a bunch of degenerate cases where you start a selection and then click inside that selection.)
- When a user clicks elsewhere or ends the selection with nothing selected, clear the selection mode.
- When a user copies text, if we have an active selection mode, pull all the selected nodes out of the DOM and filter out the ones we don't want to copy, then stitch the text back together. Although I believe this didn't work well in ~2010, it appears to work well today.
Test Plan: This mostly seems to work in Safari, Chrome, and Firefox. T12822 has some errata. I haven't tested touch events but am satisfied if the touch event story is anything better than "permanently destroys data".
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20191
2019-02-16 18:32:13 +01:00
|
|
|
-webkit-user-select: auto;
|
|
|
|
|
user-select: auto;
|
|
|
|
|
opacity: 1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-17 16:58:26 +01:00
|
|
|
.differential-diff.copy-l > tbody > tr > td.show-more:nth-child(2) {
|
|
|
|
|
-moz-user-select: none;
|
|
|
|
|
-ms-user-select: none;
|
|
|
|
|
-webkit-user-select: none;
|
|
|
|
|
user-select: none;
|
In Differential, give the "moved/copied from" gutter a more clear visual look
Summary:
Depends on D20196. See PHI985. When empty, the "moved/copied" gutter currently renders with the same background color as the rest of the line. This can be misleading because it makes code look more indented than it is, especially if you're unfamiliar with the tool:
{F6225179}
If we remove this misleading coloration, we get a white gap. This is more clear, but looks a little odd:
{F6225181}
Instead, give this gutter a subtle background fill in all casses, to make it more clear that it's a separate gutter region, not a part of the text diff:
{F6225183}
Test Plan: See screenshots. Copied text from a diff, added/removed inlines, etc.
Reviewers: amckinley
Reviewed By: amckinley
Differential Revision: https://secure.phabricator.com/D20197
2019-02-20 13:40:06 +01:00
|
|
|
opacity: 0.5;
|
2019-02-17 16:58:26 +01:00
|
|
|
}
|
|
|
|
|
|
Behold! Copy text from either side of a diff!
Summary:
Ref T12822. Ref T13161. By default, when users select text from a diff and copy it to the clipboard, they get both sides of the diff and all the line numbers. This is usually not what they intended to copy.
As of D20188, we use `content: attr(...)` to render line numbers. No browser copies this text, so that fixes line numbers.
We can use "user-select" CSS to visually prevent selection of line numbers and other stuff we don't want to copy. In Firefox and Chrome, "user-select" also applies to copied text, so getting "user-select" on the right nodes is largely good enough to do what we want.
In Safari, "user-select" is only visual, so we always need to crawl the DOM to figure out what text to pull out of it anyway.
In all browsers, we likely want to crawl the DOM anyway because this will let us show one piece of text and copy a different piece of text. We probably want to do this in the future to preserve "\t" tabs, and possibly to let us render certain character codes in one way but copy their original values. For example, we could render "\x07" as "␇".
Finally, we have to figure out which side of the diff we're copying from. The rule here is:
- If you start the selection by clicking somewhere on the left or right side of the diff, that's what you're copying.
- Otherwise, use normal document copy rules.
So the overall flow here is:
- Listen for clicks.
- When the user clicks the left or right side of the diff, store what they clicked.
- When a selection starts, and something is actually selected, check if it was initiated by clicking a diff. If it was, apply a visual effect to get "user-select" where it needs to go and show the user what we think they're doing and what we're going to copy.
- (Then, try to handle a bunch of degenerate cases where you start a selection and then click inside that selection.)
- When a user clicks elsewhere or ends the selection with nothing selected, clear the selection mode.
- When a user copies text, if we have an active selection mode, pull all the selected nodes out of the DOM and filter out the ones we don't want to copy, then stitch the text back together. Although I believe this didn't work well in ~2010, it appears to work well today.
Test Plan: This mostly seems to work in Safari, Chrome, and Firefox. T12822 has some errata. I haven't tested touch events but am satisfied if the touch event story is anything better than "permanently destroys data".
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20191
2019-02-16 18:32:13 +01:00
|
|
|
.differential-diff.copy-r > tbody > tr > td:nth-child(5) {
|
2019-02-17 16:58:26 +01:00
|
|
|
-moz-user-select: auto;
|
|
|
|
|
-ms-user-select: auto;
|
Behold! Copy text from either side of a diff!
Summary:
Ref T12822. Ref T13161. By default, when users select text from a diff and copy it to the clipboard, they get both sides of the diff and all the line numbers. This is usually not what they intended to copy.
As of D20188, we use `content: attr(...)` to render line numbers. No browser copies this text, so that fixes line numbers.
We can use "user-select" CSS to visually prevent selection of line numbers and other stuff we don't want to copy. In Firefox and Chrome, "user-select" also applies to copied text, so getting "user-select" on the right nodes is largely good enough to do what we want.
In Safari, "user-select" is only visual, so we always need to crawl the DOM to figure out what text to pull out of it anyway.
In all browsers, we likely want to crawl the DOM anyway because this will let us show one piece of text and copy a different piece of text. We probably want to do this in the future to preserve "\t" tabs, and possibly to let us render certain character codes in one way but copy their original values. For example, we could render "\x07" as "␇".
Finally, we have to figure out which side of the diff we're copying from. The rule here is:
- If you start the selection by clicking somewhere on the left or right side of the diff, that's what you're copying.
- Otherwise, use normal document copy rules.
So the overall flow here is:
- Listen for clicks.
- When the user clicks the left or right side of the diff, store what they clicked.
- When a selection starts, and something is actually selected, check if it was initiated by clicking a diff. If it was, apply a visual effect to get "user-select" where it needs to go and show the user what we think they're doing and what we're going to copy.
- (Then, try to handle a bunch of degenerate cases where you start a selection and then click inside that selection.)
- When a user clicks elsewhere or ends the selection with nothing selected, clear the selection mode.
- When a user copies text, if we have an active selection mode, pull all the selected nodes out of the DOM and filter out the ones we don't want to copy, then stitch the text back together. Although I believe this didn't work well in ~2010, it appears to work well today.
Test Plan: This mostly seems to work in Safari, Chrome, and Firefox. T12822 has some errata. I haven't tested touch events but am satisfied if the touch event story is anything better than "permanently destroys data".
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161, T12822
Differential Revision: https://secure.phabricator.com/D20191
2019-02-16 18:32:13 +01:00
|
|
|
-webkit-user-select: auto;
|
|
|
|
|
user-select: auto;
|
|
|
|
|
opacity: 1;
|
|
|
|
|
}
|
In Differential, give the "moved/copied from" gutter a more clear visual look
Summary:
Depends on D20196. See PHI985. When empty, the "moved/copied" gutter currently renders with the same background color as the rest of the line. This can be misleading because it makes code look more indented than it is, especially if you're unfamiliar with the tool:
{F6225179}
If we remove this misleading coloration, we get a white gap. This is more clear, but looks a little odd:
{F6225181}
Instead, give this gutter a subtle background fill in all casses, to make it more clear that it's a separate gutter region, not a part of the text diff:
{F6225183}
Test Plan: See screenshots. Copied text from a diff, added/removed inlines, etc.
Reviewers: amckinley
Reviewed By: amckinley
Differential Revision: https://secure.phabricator.com/D20197
2019-02-20 13:40:06 +01:00
|
|
|
|
|
|
|
|
.differential-diff.copy-l > tbody > tr.inline > td,
|
|
|
|
|
.differential-diff.copy-r > tbody > tr.inline > td {
|
|
|
|
|
-moz-user-select: none;
|
|
|
|
|
-ms-user-select: none;
|
|
|
|
|
-webkit-user-select: none;
|
|
|
|
|
user-select: none;
|
|
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
