Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
/**
|
2017-05-08 18:52:16 +02:00
|
|
|
* @provides phabricator-diff-changeset
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
* @requires javelin-dom
|
|
|
|
* javelin-util
|
|
|
|
* javelin-stratcom
|
|
|
|
* javelin-install
|
|
|
|
* javelin-workflow
|
|
|
|
* javelin-router
|
|
|
|
* javelin-behavior-device
|
|
|
|
* javelin-vector
|
2017-05-09 21:09:45 +02:00
|
|
|
* phabricator-diff-inline
|
2020-04-21 18:56:30 +02:00
|
|
|
* phabricator-diff-path-view
|
2020-04-23 17:50:46 +02:00
|
|
|
* phuix-button-view
|
2017-05-09 21:09:45 +02:00
|
|
|
* @javelin
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
*/
|
|
|
|
|
2017-05-08 18:52:16 +02:00
|
|
|
JX.install('DiffChangeset', {
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
|
|
|
construct : function(node) {
|
|
|
|
this._node = node;
|
|
|
|
|
|
|
|
var data = this._getNodeData();
|
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
|
|
|
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
this._renderURI = data.renderURI;
|
|
|
|
this._ref = data.ref;
|
Use ChangesetListView on Differential standalone view
Summary:
Fixes T4452. Ref T2009. There's a hierarchy of changeset rendering power: only low-level calls, use of ChangesetDetailView, then use of ChangesetListView (a list of DetailViews).
Prior to work here, the various changeset rendering controllers got their hands dirty to varying degrees, with some using only the lowest-level rendering pipeline:
- Phriction: no view (lowest level)
- Diffusion: DetailView
- Differential Changeset: DetailView
- Differential Diff: ListView
- Differential Revision: ListView
I brought Phriction up to use DetailView, but want to bring everything all the way up to use ListView. Each composition layer adds more features to diff browsing. In particular, this change enables "Highlight As", switching 1up vs 2up, adding inlines, etc., on the standalone view.
Test Plan:
- Viewed a changeset standalone. Could change highlighting, switch 1up vs 2up, add and edit inlines, etc.
- Viewed a revision; no behavioral changes.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T4452, T2009
Differential Revision: https://secure.phabricator.com/D12012
2015-03-08 12:10:11 +01:00
|
|
|
this._loaded = data.loaded;
|
2018-02-09 01:55:54 +01:00
|
|
|
this._treeNodeID = data.treeNodeID;
|
2017-05-09 21:09:45 +02:00
|
|
|
|
2017-05-16 23:53:21 +02:00
|
|
|
this._leftID = data.left;
|
|
|
|
this._rightID = data.right;
|
|
|
|
|
2017-05-19 01:31:16 +02:00
|
|
|
this._displayPath = JX.$H(data.displayPath);
|
2020-04-21 18:56:30 +02:00
|
|
|
this._pathParts = data.pathParts;
|
2017-05-18 20:54:58 +02:00
|
|
|
this._icon = data.icon;
|
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
|
|
|
|
2020-04-17 18:25:53 +02:00
|
|
|
this._editorURI = data.editorURI;
|
|
|
|
this._editorConfigureURI = data.editorConfigureURI;
|
2020-04-23 16:30:21 +02:00
|
|
|
this._showPathURI = data.showPathURI;
|
|
|
|
this._showDirectoryURI = data.showDirectoryURI;
|
2020-04-17 18:25:53 +02:00
|
|
|
|
2020-04-22 17:11:45 +02:00
|
|
|
this._pathIconIcon = data.pathIconIcon;
|
|
|
|
this._pathIconColor = data.pathIconColor;
|
2020-04-22 19:56:09 +02:00
|
|
|
this._isLowImportance = data.isLowImportance;
|
|
|
|
this._isOwned = data.isOwned;
|
2020-04-22 22:13:15 +02:00
|
|
|
this._isLoading = true;
|
2020-04-22 17:11:45 +02:00
|
|
|
|
2017-05-09 21:09:45 +02:00
|
|
|
this._inlines = [];
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
|
|
|
|
if (data.changesetState) {
|
|
|
|
this._loadChangesetState(data.changesetState);
|
|
|
|
}
|
2020-04-23 17:50:46 +02:00
|
|
|
|
2020-05-14 21:49:29 +02:00
|
|
|
JX.enableDispatch(window, 'selectstart');
|
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var onselect = JX.bind(this, this._onClickHeader);
|
2020-05-14 21:49:29 +02:00
|
|
|
JX.DOM.listen(
|
|
|
|
this._node,
|
|
|
|
['mousedown', 'selectstart'],
|
|
|
|
'changeset-header',
|
|
|
|
onselect);
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
},
|
|
|
|
|
|
|
|
members: {
|
|
|
|
_node: null,
|
|
|
|
_loaded: false,
|
|
|
|
_sequence: 0,
|
|
|
|
_stabilize: false,
|
|
|
|
|
|
|
|
_renderURI: null,
|
|
|
|
_ref: null,
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
_rendererKey: null,
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
_highlight: null,
|
2020-05-12 20:37:55 +02:00
|
|
|
_requestDocumentEngineKey: null,
|
|
|
|
_responseDocumentEngineKey: null,
|
2020-05-12 22:24:53 +02:00
|
|
|
_availableDocumentEngineKeys: null,
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
_characterEncoding: null,
|
2015-03-08 23:27:16 +01:00
|
|
|
_undoTemplates: null,
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
2017-05-16 23:53:21 +02:00
|
|
|
_leftID: null,
|
|
|
|
_rightID: null,
|
|
|
|
|
2017-05-09 21:09:45 +02:00
|
|
|
_inlines: null,
|
2017-05-17 21:51:29 +02:00
|
|
|
_visible: true,
|
|
|
|
|
2017-05-19 01:31:16 +02:00
|
|
|
_displayPath: null,
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
2017-05-18 20:54:58 +02:00
|
|
|
_changesetList: null,
|
|
|
|
_icon: null,
|
|
|
|
|
2020-04-17 18:25:53 +02:00
|
|
|
_editorURI: null,
|
|
|
|
_editorConfigureURI: null,
|
2020-04-23 16:30:21 +02:00
|
|
|
_showPathURI: null,
|
|
|
|
_showDirectoryURI: null,
|
|
|
|
|
2020-04-21 18:56:30 +02:00
|
|
|
_pathView: null,
|
2020-04-17 18:25:53 +02:00
|
|
|
|
2020-04-22 17:11:45 +02:00
|
|
|
_pathIconIcon: null,
|
|
|
|
_pathIconColor: null,
|
2020-04-22 19:56:09 +02:00
|
|
|
_isLowImportance: null,
|
|
|
|
_isOwned: null,
|
2020-04-22 22:13:15 +02:00
|
|
|
_isHidden: null,
|
2020-04-23 17:50:46 +02:00
|
|
|
_isSelected: false,
|
|
|
|
_viewMenu: null,
|
2020-04-22 17:11:45 +02:00
|
|
|
|
2020-04-17 18:25:53 +02:00
|
|
|
getEditorURI: function() {
|
|
|
|
return this._editorURI;
|
|
|
|
},
|
|
|
|
|
|
|
|
getEditorConfigureURI: function() {
|
|
|
|
return this._editorConfigureURI;
|
|
|
|
},
|
|
|
|
|
2020-04-23 16:30:21 +02:00
|
|
|
getShowPathURI: function() {
|
|
|
|
return this._showPathURI;
|
|
|
|
},
|
|
|
|
|
|
|
|
getShowDirectoryURI: function() {
|
|
|
|
return this._showDirectoryURI;
|
|
|
|
},
|
|
|
|
|
2017-05-16 23:53:21 +02:00
|
|
|
getLeftChangesetID: function() {
|
|
|
|
return this._leftID;
|
|
|
|
},
|
|
|
|
|
|
|
|
getRightChangesetID: function() {
|
|
|
|
return this._rightID;
|
|
|
|
},
|
|
|
|
|
2017-05-18 20:54:58 +02:00
|
|
|
setChangesetList: function(list) {
|
|
|
|
this._changesetList = list;
|
|
|
|
return this;
|
|
|
|
},
|
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
setViewMenu: function(menu) {
|
|
|
|
this._viewMenu = menu;
|
|
|
|
return this;
|
|
|
|
},
|
|
|
|
|
2017-05-18 20:54:58 +02:00
|
|
|
getIcon: function() {
|
|
|
|
if (!this._visible) {
|
|
|
|
return 'fa-file-o';
|
|
|
|
}
|
|
|
|
|
|
|
|
return this._icon;
|
|
|
|
},
|
|
|
|
|
|
|
|
getColor: function() {
|
|
|
|
if (!this._visible) {
|
|
|
|
return 'grey';
|
|
|
|
}
|
|
|
|
|
|
|
|
return 'blue';
|
|
|
|
},
|
|
|
|
|
|
|
|
getChangesetList: function() {
|
|
|
|
return this._changesetList;
|
|
|
|
},
|
|
|
|
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
/**
|
|
|
|
* Has the content of this changeset been loaded?
|
|
|
|
*
|
|
|
|
* This method returns `true` if a request has been fired, even if the
|
|
|
|
* response has not returned yet.
|
|
|
|
*
|
|
|
|
* @return bool True if the content has been loaded.
|
|
|
|
*/
|
|
|
|
isLoaded: function() {
|
|
|
|
return this._loaded;
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Configure stabilization of the document position on content load.
|
|
|
|
*
|
|
|
|
* When we dump the changeset into the document, we can try to stabilize
|
|
|
|
* the document scroll position so that the user doesn't feel like they
|
|
|
|
* are jumping around as things load in. This is generally useful when
|
|
|
|
* populating initial changes.
|
|
|
|
*
|
|
|
|
* However, if a user explicitly requests a content load by clicking a
|
|
|
|
* "Load" link or using the dropdown menu, this stabilization generally
|
|
|
|
* feels unnatural, so we don't use it in response to explicit user action.
|
|
|
|
*
|
|
|
|
* @param bool True to stabilize the next content fill.
|
|
|
|
* @return this
|
|
|
|
*/
|
|
|
|
setStabilize: function(stabilize) {
|
|
|
|
this._stabilize = stabilize;
|
|
|
|
return this;
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Should this changeset load immediately when the page loads?
|
|
|
|
*
|
|
|
|
* Normally, changes load immediately, but if a diff or commit is very
|
|
|
|
* large we stop doing this and have the user load files explicitly, or
|
|
|
|
* choose to load everything.
|
|
|
|
*
|
|
|
|
* @return bool True if the changeset should load automatically when the
|
|
|
|
* page loads.
|
|
|
|
*/
|
|
|
|
shouldAutoload: function() {
|
|
|
|
return this._getNodeData().autoload;
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Load this changeset, if it isn't already loading.
|
|
|
|
*
|
|
|
|
* This fires a request to fill the content of this changeset, provided
|
|
|
|
* there isn't already a request in flight. To force a reload, use
|
|
|
|
* @{method:reload}.
|
|
|
|
*
|
|
|
|
* @return this
|
|
|
|
*/
|
|
|
|
load: function() {
|
|
|
|
if (this._loaded) {
|
|
|
|
return this;
|
|
|
|
}
|
|
|
|
|
|
|
|
return this.reload();
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Reload the changeset content.
|
|
|
|
*
|
|
|
|
* This method always issues a request, even if the content is already
|
|
|
|
* loading. To load conditionally, use @{method:load}.
|
|
|
|
*
|
|
|
|
* @return this
|
|
|
|
*/
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
reload: function(state) {
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
this._loaded = true;
|
|
|
|
this._sequence++;
|
|
|
|
|
2020-04-22 22:13:15 +02:00
|
|
|
var workflow = this._newReloadWorkflow(state)
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
.setHandler(JX.bind(this, this._onresponse, this._sequence));
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
this._startContentWorkflow(workflow);
|
|
|
|
|
2020-04-22 22:13:15 +02:00
|
|
|
var pht = this.getChangesetList().getTranslations();
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
JX.DOM.setContent(
|
|
|
|
this._getContentFrame(),
|
|
|
|
JX.$N(
|
|
|
|
'div',
|
|
|
|
{className: 'differential-loading'},
|
2017-05-08 20:27:11 +02:00
|
|
|
pht('Loading...')));
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
|
|
|
|
return this;
|
|
|
|
},
|
|
|
|
|
2020-04-22 22:13:15 +02:00
|
|
|
_newReloadWorkflow: function(state) {
|
|
|
|
var params = this._getViewParameters(state);
|
|
|
|
return new JX.Workflow(this._renderURI, params);
|
|
|
|
},
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
/**
|
|
|
|
* Load missing context in a changeset.
|
|
|
|
*
|
|
|
|
* We do this when the user clicks "Show X Lines". We also expand all of
|
2016-01-13 15:19:31 +01:00
|
|
|
* the missing context when they "Show All Context".
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
*
|
|
|
|
* @param string Line range specification, like "0-40/0-20".
|
|
|
|
* @param node Row where the context should be rendered after loading.
|
|
|
|
* @param bool True if this is a bulk load of multiple context blocks.
|
|
|
|
* @return this
|
|
|
|
*/
|
|
|
|
loadContext: function(range, target, bulk) {
|
|
|
|
var params = this._getViewParameters();
|
|
|
|
params.range = range;
|
|
|
|
|
2017-05-08 20:27:11 +02:00
|
|
|
var pht = this.getChangesetList().getTranslations();
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
var container = JX.DOM.scry(target, 'td')[0];
|
2017-05-08 20:27:11 +02:00
|
|
|
JX.DOM.setContent(container, pht('Loading...'));
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
JX.DOM.alterClass(target, 'differential-show-more-loading', true);
|
|
|
|
|
|
|
|
var workflow = new JX.Workflow(this._renderURI, params)
|
|
|
|
.setHandler(JX.bind(this, this._oncontext, target));
|
|
|
|
|
|
|
|
if (bulk) {
|
|
|
|
// If we're loading a bunch of these because the viewer clicked
|
2016-01-13 15:19:31 +01:00
|
|
|
// "Show All Context" or similar, use lower-priority requests
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
// and draw a progress bar.
|
|
|
|
this._startContentWorkflow(workflow);
|
|
|
|
} else {
|
|
|
|
// If this is a single click on a context link, use a higher priority
|
|
|
|
// load without a chrome change.
|
|
|
|
workflow.start();
|
|
|
|
}
|
|
|
|
|
|
|
|
return this;
|
|
|
|
},
|
|
|
|
|
2017-05-08 19:20:59 +02:00
|
|
|
loadAllContext: function() {
|
|
|
|
var nodes = JX.DOM.scry(this._node, 'tr', 'context-target');
|
|
|
|
for (var ii = 0; ii < nodes.length; ii++) {
|
|
|
|
var show = JX.DOM.scry(nodes[ii], 'a', 'show-more');
|
|
|
|
for (var jj = 0; jj < show.length; jj++) {
|
|
|
|
var data = JX.Stratcom.getData(show[jj]);
|
|
|
|
if (data.type != 'all') {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
this.loadContext(data.range, nodes[ii], true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
_startContentWorkflow: function(workflow) {
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
var routable = workflow.getRoutable();
|
|
|
|
|
|
|
|
routable
|
|
|
|
.setPriority(500)
|
|
|
|
.setType('content')
|
|
|
|
.setKey(this._getRoutableKey());
|
|
|
|
|
|
|
|
JX.Router.getInstance().queue(routable);
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
},
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
2017-05-19 01:31:16 +02:00
|
|
|
getDisplayPath: function() {
|
|
|
|
return this._displayPath;
|
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
|
|
|
},
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
/**
|
|
|
|
* Receive a response to a context request.
|
|
|
|
*/
|
|
|
|
_oncontext: function(target, response) {
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 21:07:46 +02:00
|
|
|
// TODO: This should be better structured.
|
|
|
|
// If the response comes back with several top-level nodes, the last one
|
|
|
|
// is the actual context; the others are headers. Add any headers first,
|
|
|
|
// then copy the new rows into the document.
|
|
|
|
var markup = JX.$H(response.changeset).getFragment();
|
|
|
|
var len = markup.childNodes.length;
|
|
|
|
var diff = JX.DOM.findAbove(target, 'table', 'differential-diff');
|
|
|
|
|
|
|
|
for (var ii = 0; ii < len - 1; ii++) {
|
|
|
|
diff.parentNode.insertBefore(markup.firstChild, diff);
|
|
|
|
}
|
|
|
|
|
|
|
|
var table = markup.firstChild;
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
var root = target.parentNode;
|
|
|
|
this._moveRows(table, root, target);
|
|
|
|
root.removeChild(target);
|
2015-03-08 23:27:16 +01:00
|
|
|
|
|
|
|
this._onchangesetresponse(response);
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
},
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
_moveRows: function(src, dst, before) {
|
|
|
|
var rows = JX.DOM.scry(src, 'tr');
|
|
|
|
for (var ii = 0; ii < rows.length; ii++) {
|
|
|
|
|
|
|
|
// Find the table this <tr /> belongs to. If it's a sub-table, like a
|
|
|
|
// table in an inline comment, don't copy it.
|
|
|
|
if (JX.DOM.findAbove(rows[ii], 'table') !== src) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (before) {
|
|
|
|
dst.insertBefore(rows[ii], before);
|
|
|
|
} else {
|
|
|
|
dst.appendChild(rows[ii]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get parameters which define the current rendering options.
|
|
|
|
*/
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
_getViewParameters: function(state) {
|
|
|
|
var parameters = {
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
ref: this._ref,
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
device: this._getDefaultDeviceRenderer()
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
};
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
|
|
|
|
if (state) {
|
|
|
|
JX.copy(parameters, state);
|
|
|
|
}
|
|
|
|
|
|
|
|
return parameters;
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
},
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the active @{class:JX.Routable} for this changeset.
|
|
|
|
*
|
|
|
|
* After issuing a request with @{method:load} or @{method:reload}, you
|
|
|
|
* can adjust routable settings (like priority) by querying the routable
|
|
|
|
* with this method. Note that there may not be a current routable.
|
|
|
|
*
|
|
|
|
* @return JX.Routable|null Active routable, if one exists.
|
|
|
|
*/
|
|
|
|
getRoutable: function() {
|
|
|
|
return JX.Router.getInstance().getRoutableByKey(this._getRoutableKey());
|
|
|
|
},
|
|
|
|
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
getRendererKey: function() {
|
|
|
|
return this._rendererKey;
|
2014-06-20 20:49:41 +02:00
|
|
|
},
|
|
|
|
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
_getDefaultDeviceRenderer: function() {
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
// NOTE: If you load the page at one device resolution and then resize to
|
|
|
|
// a different one we don't re-render the diffs, because it's a
|
|
|
|
// complicated mess and you could lose inline comments, cursor positions,
|
|
|
|
// etc.
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 23:03:00 +01:00
|
|
|
return (JX.Device.getDevice() == 'desktop') ? '2up' : '1up';
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
},
|
|
|
|
|
2015-03-08 23:27:16 +01:00
|
|
|
getUndoTemplates: function() {
|
|
|
|
return this._undoTemplates;
|
|
|
|
},
|
|
|
|
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
getCharacterEncoding: function() {
|
|
|
|
return this._characterEncoding;
|
2014-06-20 20:49:41 +02:00
|
|
|
},
|
|
|
|
|
|
|
|
getHighlight: function() {
|
|
|
|
return this._highlight;
|
|
|
|
},
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
2020-05-12 20:37:55 +02:00
|
|
|
getRequestDocumentEngineKey: function() {
|
|
|
|
return this._requestDocumentEngineKey;
|
|
|
|
},
|
|
|
|
|
|
|
|
getResponseDocumentEngineKey: function() {
|
|
|
|
return this._responseDocumentEngineKey;
|
2019-09-25 19:43:21 +02:00
|
|
|
},
|
|
|
|
|
2020-05-12 22:24:53 +02:00
|
|
|
getAvailableDocumentEngineKeys: function() {
|
|
|
|
return this._availableDocumentEngineKeys;
|
|
|
|
},
|
|
|
|
|
2017-05-08 22:24:15 +02:00
|
|
|
getSelectableItems: function() {
|
|
|
|
var items = [];
|
|
|
|
|
|
|
|
items.push({
|
|
|
|
type: 'file',
|
|
|
|
changeset: this,
|
|
|
|
target: this,
|
|
|
|
nodes: {
|
|
|
|
begin: this._node,
|
|
|
|
end: null
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2017-05-17 21:51:29 +02:00
|
|
|
if (!this._visible) {
|
|
|
|
return items;
|
|
|
|
}
|
|
|
|
|
2017-05-08 22:24:15 +02:00
|
|
|
var rows = JX.DOM.scry(this._node, 'tr');
|
|
|
|
|
|
|
|
var blocks = [];
|
|
|
|
var block;
|
|
|
|
var ii;
|
|
|
|
for (ii = 0; ii < rows.length; ii++) {
|
|
|
|
var type = this._getRowType(rows[ii]);
|
|
|
|
|
|
|
|
if (!block || (block.type !== type)) {
|
|
|
|
block = {
|
|
|
|
type: type,
|
|
|
|
items: []
|
|
|
|
};
|
|
|
|
blocks.push(block);
|
|
|
|
}
|
|
|
|
|
|
|
|
block.items.push(rows[ii]);
|
|
|
|
}
|
|
|
|
|
2017-06-03 15:21:45 +02:00
|
|
|
var last_inline = null;
|
|
|
|
var last_inline_item = null;
|
2017-05-08 22:24:15 +02:00
|
|
|
for (ii = 0; ii < blocks.length; ii++) {
|
|
|
|
block = blocks[ii];
|
|
|
|
|
|
|
|
if (block.type == 'change') {
|
|
|
|
items.push({
|
|
|
|
type: block.type,
|
|
|
|
changeset: this,
|
|
|
|
target: block.items[0],
|
|
|
|
nodes: {
|
|
|
|
begin: block.items[0],
|
|
|
|
end: block.items[block.items.length - 1]
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
if (block.type == 'comment') {
|
|
|
|
for (var jj = 0; jj < block.items.length; jj++) {
|
2017-05-16 02:31:58 +02:00
|
|
|
var inline = this.getInlineForRow(block.items[jj]);
|
|
|
|
|
2017-06-03 15:21:45 +02:00
|
|
|
// When comments are being edited, they have a hidden row with
|
|
|
|
// the actual comment and then a visible row with the editor.
|
|
|
|
|
|
|
|
// In this case, we only want to generate one item, but it should
|
|
|
|
// use the editor as a scroll target. To accomplish this, check if
|
|
|
|
// this row has the same inline as the previous row. If so, update
|
|
|
|
// the last item to use this row's nodes.
|
|
|
|
|
|
|
|
if (inline === last_inline) {
|
|
|
|
last_inline_item.nodes.begin = block.items[jj];
|
|
|
|
last_inline_item.nodes.end = block.items[jj];
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
last_inline = inline;
|
|
|
|
}
|
|
|
|
|
2017-06-03 15:42:52 +02:00
|
|
|
var is_saved = (!inline.isDraft() && !inline.isEditing());
|
|
|
|
|
2017-06-03 15:21:45 +02:00
|
|
|
last_inline_item = {
|
2017-05-08 22:24:15 +02:00
|
|
|
type: block.type,
|
|
|
|
changeset: this,
|
2017-05-16 16:24:20 +02:00
|
|
|
target: inline,
|
2017-06-15 13:51:06 +02:00
|
|
|
hidden: inline.isHidden(),
|
2017-06-15 13:17:01 +02:00
|
|
|
collapsed: inline.isCollapsed(),
|
2017-06-03 15:21:45 +02:00
|
|
|
deleted: !inline.getID() && !inline.isEditing(),
|
2017-05-08 22:24:15 +02:00
|
|
|
nodes: {
|
|
|
|
begin: block.items[jj],
|
|
|
|
end: block.items[jj]
|
2017-06-03 15:21:45 +02:00
|
|
|
},
|
|
|
|
attributes: {
|
2017-06-03 15:31:09 +02:00
|
|
|
unsaved: inline.isEditing(),
|
2017-06-15 13:28:21 +02:00
|
|
|
anyDraft: inline.isDraft() || inline.isDraftDone(),
|
2017-06-03 15:42:52 +02:00
|
|
|
undone: (is_saved && !inline.isDone()),
|
|
|
|
done: (is_saved && inline.isDone())
|
2017-05-08 22:24:15 +02:00
|
|
|
}
|
2017-06-03 15:21:45 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
items.push(last_inline_item);
|
2017-05-08 22:24:15 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return items;
|
|
|
|
},
|
|
|
|
|
|
|
|
_getRowType: function(row) {
|
|
|
|
// NOTE: Don't do "className.indexOf()" elsewhere. This is evil legacy
|
|
|
|
// magic.
|
|
|
|
|
|
|
|
if (row.className.indexOf('inline') !== -1) {
|
|
|
|
return 'comment';
|
|
|
|
}
|
|
|
|
|
|
|
|
var cells = JX.DOM.scry(row, 'td');
|
|
|
|
for (var ii = 0; ii < cells.length; ii++) {
|
|
|
|
if (cells[ii].className.indexOf('old') !== -1 ||
|
|
|
|
cells[ii].className.indexOf('new') !== -1) {
|
|
|
|
return 'change';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
_getNodeData: function() {
|
|
|
|
return JX.Stratcom.getData(this._node);
|
|
|
|
},
|
|
|
|
|
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
|
|
|
getVectors: function() {
|
|
|
|
return {
|
|
|
|
pos: JX.$V(this._node),
|
|
|
|
dim: JX.Vector.getDim(this._node)
|
|
|
|
};
|
|
|
|
},
|
|
|
|
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
_onresponse: function(sequence, response) {
|
|
|
|
if (sequence != this._sequence) {
|
|
|
|
// If this isn't the most recent request, ignore it. This normally
|
|
|
|
// means the user changed view settings between the time the page loaded
|
|
|
|
// and the content filled.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// As we populate the changeset list, we try to hold the document scroll
|
|
|
|
// position steady, so that, e.g., users who want to leave a comment on a
|
|
|
|
// diff with a large number of changes don't constantly have the text
|
|
|
|
// area scrolled off the bottom of the screen until the entire diff loads.
|
|
|
|
//
|
2017-05-31 02:41:30 +02:00
|
|
|
// There are several major cases here:
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
//
|
|
|
|
// - If we're near the top of the document, never scroll.
|
2017-05-31 02:41:30 +02:00
|
|
|
// - If we're near the bottom of the document, always scroll, unless
|
|
|
|
// we have an anchor.
|
|
|
|
// - Otherwise, scroll if the changes were above (or, at least,
|
|
|
|
// almost entirely above) the viewport.
|
|
|
|
//
|
|
|
|
// We don't scroll if the changes were just near the top of the viewport
|
|
|
|
// because this makes us scroll incorrectly when an anchored change is
|
|
|
|
// visible. See T12779.
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
|
|
|
var target = this._node;
|
|
|
|
|
|
|
|
var old_pos = JX.Vector.getScroll();
|
|
|
|
var old_view = JX.Vector.getViewport();
|
|
|
|
var old_dim = JX.Vector.getDocument();
|
|
|
|
|
|
|
|
// Number of pixels away from the top or bottom of the document which
|
|
|
|
// count as "nearby".
|
|
|
|
var sticky = 480;
|
|
|
|
|
|
|
|
var near_top = (old_pos.y <= sticky);
|
|
|
|
var near_bot = ((old_pos.y + old_view.y) >= (old_dim.y - sticky));
|
|
|
|
|
If there's an anchor in the URL in Differential, don't stick to the bottom of the page as content loads
Summary:
Fixes T11784. A lot of things are interacting here, but this probably gets slightly better results slightly more often?
Basically:
- When we load content, we try to keep the viewport "stable" on the page, so the page doesn't jump around like crazy.
- If you're near the top or bottom of the page, we try to stick to the top (e.g., reading the summary) or bottom (e.g., writing a comment).
- But, if you followed an anchor to a comment that's close to the bottom of the page, we might stick to the bottom intead of staying with the anchor.
Kind of do a better job by not sticking to the bottom if you have an anchor. This will get things wrong if you follow an anchor, scroll down, start writing a comment, etc. But this whole thing is a pile of guesses anyway.
Test Plan:
- Followed an anchor, saw non-sticky stabilization.
- Loaded the page normally, scrolled to the bottom real fast, saw sticky stabilization.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11784
Differential Revision: https://secure.phabricator.com/D17911
2017-05-16 19:18:31 +02:00
|
|
|
// If we have an anchor in the URL, never stick to the bottom of the
|
|
|
|
// page. See T11784 for discussion.
|
|
|
|
if (window.location.hash) {
|
|
|
|
near_bot = false;
|
|
|
|
}
|
|
|
|
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
var target_pos = JX.Vector.getPos(target);
|
|
|
|
var target_dim = JX.Vector.getDim(target);
|
2017-05-31 02:41:30 +02:00
|
|
|
var target_bot = (target_pos.y + target_dim.y);
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
2017-05-31 02:41:30 +02:00
|
|
|
// Detect if the changeset is entirely (or, at least, almost entirely)
|
2017-06-01 19:41:57 +02:00
|
|
|
// above us. The height here is roughly the height of the persistent
|
|
|
|
// banner.
|
|
|
|
var above_screen = (target_bot < old_pos.y + 64);
|
|
|
|
|
|
|
|
// If we have a URL anchor and are currently nearby, stick to it
|
|
|
|
// no matter what.
|
|
|
|
var on_target = null;
|
|
|
|
if (window.location.hash) {
|
|
|
|
try {
|
|
|
|
var anchor = JX.$(window.location.hash.replace('#', ''));
|
|
|
|
if (anchor) {
|
|
|
|
var anchor_pos = JX.$V(anchor);
|
|
|
|
if ((anchor_pos.y > old_pos.y) &&
|
|
|
|
(anchor_pos.y < old_pos.y + 96)) {
|
|
|
|
on_target = anchor;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} catch (ignored) {
|
|
|
|
// If we have a bogus anchor, just ignore it.
|
|
|
|
}
|
|
|
|
}
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
|
|
|
var frame = this._getContentFrame();
|
|
|
|
JX.DOM.setContent(frame, JX.$H(response.changeset));
|
|
|
|
|
|
|
|
if (this._stabilize) {
|
2017-06-01 19:41:57 +02:00
|
|
|
if (on_target) {
|
|
|
|
JX.DOM.scrollToPosition(old_pos.x, JX.$V(on_target).y - 60);
|
|
|
|
} else if (!near_top) {
|
2017-05-31 02:41:30 +02:00
|
|
|
if (near_bot || above_screen) {
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
// Figure out how much taller the document got.
|
|
|
|
var delta = (JX.Vector.getDocument().y - old_dim.y);
|
2015-01-25 17:42:40 +01:00
|
|
|
JX.DOM.scrollToPosition(old_pos.x, old_pos.y + delta);
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
this._stabilize = false;
|
|
|
|
}
|
|
|
|
|
2015-03-08 23:27:16 +01:00
|
|
|
this._onchangesetresponse(response);
|
|
|
|
},
|
|
|
|
|
|
|
|
_onchangesetresponse: function(response) {
|
|
|
|
// Code shared by autoload and context responses.
|
|
|
|
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
this._loadChangesetState(response);
|
|
|
|
|
|
|
|
JX.Stratcom.invoke('differential-inline-comment-refresh');
|
|
|
|
|
|
|
|
this._rebuildAllInlines();
|
|
|
|
|
|
|
|
JX.Stratcom.invoke('resize');
|
|
|
|
},
|
|
|
|
|
|
|
|
_loadChangesetState: function(state) {
|
|
|
|
if (state.coverage) {
|
|
|
|
for (var k in state.coverage) {
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
try {
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
JX.DOM.replace(JX.$(k), JX.$H(state.coverage[k]));
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
} catch (ignored) {
|
|
|
|
// Not terribly important.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-03-08 23:27:16 +01:00
|
|
|
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
if (state.undoTemplates) {
|
|
|
|
this._undoTemplates = state.undoTemplates;
|
2015-03-08 23:27:16 +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
|
|
|
|
Make "renderer", "engine", and "encoding" sticky across reloads in Differential and Diffusion
Summary:
Ref T13455. Update the other "view state" properties to work like "highlight" now works.
Some complexity here arises from these concerns:
- In "View Standalone", we render the changeset inline. This is useful for debugging/development, and desirable to retain.
- In all other cases, we render the changeset with AJAX.
So the client needs to be able to learn about the "state" properties of the changeset on two different flows. Prior to this change, each pathway had a fair amount of unique code.
Then, some bookkeeping issues:
- At inital rendering time, we may not know which renderer will be selected: it may be based on the client viewport dimensions.
- Prior to this change, the client didn't separate "value of the property for the changeset as rendered" and "desired value of the property".
Test Plan:
- Viewed changes in Differential, Diffusion, and in standalone mode.
- Toggled renderer, character sets, and document engine (this one isn't terribly useful). Reloaded, saw them stick.
- Started typing a comment, cancelled it, hit the undo UI.
Maniphest Tasks: T13455
Differential Revision: https://secure.phabricator.com/D21138
2020-04-18 00:39:47 +02:00
|
|
|
this._rendererKey = state.rendererKey;
|
|
|
|
this._highlight = state.highlight;
|
|
|
|
this._characterEncoding = state.characterEncoding;
|
2020-05-12 20:37:55 +02:00
|
|
|
this._requestDocumentEngineKey = state.requestDocumentEngineKey;
|
|
|
|
this._responseDocumentEngineKey = state.responseDocumentEngineKey;
|
2020-05-12 22:24:53 +02:00
|
|
|
this._availableDocumentEngineKeys = state.availableDocumentEngineKeys;
|
2020-04-22 22:13:15 +02:00
|
|
|
this._isHidden = state.isHidden;
|
|
|
|
|
|
|
|
var is_hidden = !this.isVisible();
|
|
|
|
if (this._isHidden != is_hidden) {
|
|
|
|
this.setVisible(!this._isHidden);
|
|
|
|
}
|
|
|
|
|
|
|
|
this._isLoading = false;
|
|
|
|
this.getPathView().setIsLoading(this._isLoading);
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
},
|
|
|
|
|
|
|
|
_getContentFrame: function() {
|
|
|
|
return JX.DOM.find(this._node, 'div', 'changeset-view-content');
|
|
|
|
},
|
|
|
|
|
|
|
|
_getRoutableKey: function() {
|
|
|
|
return 'changeset-view.' + this._ref + '.' + this._sequence;
|
2017-05-09 21:09:45 +02:00
|
|
|
},
|
|
|
|
|
|
|
|
getInlineForRow: function(node) {
|
|
|
|
var data = JX.Stratcom.getData(node);
|
|
|
|
|
|
|
|
if (!data.inline) {
|
2017-05-16 01:26:45 +02:00
|
|
|
var inline = new JX.DiffInline()
|
|
|
|
.setChangeset(this)
|
|
|
|
.bindToRow(node);
|
2017-05-09 21:09:45 +02:00
|
|
|
|
|
|
|
this._inlines.push(inline);
|
|
|
|
}
|
|
|
|
|
|
|
|
return data.inline;
|
2017-05-16 00:03:30 +02:00
|
|
|
},
|
|
|
|
|
2020-05-14 00:27:11 +02:00
|
|
|
newInlineForRange: function(origin, target, options) {
|
2017-05-17 01:52:31 +02:00
|
|
|
var list = this.getChangesetList();
|
|
|
|
|
|
|
|
var src = list.getLineNumberFromHeader(origin);
|
|
|
|
var dst = list.getLineNumberFromHeader(target);
|
|
|
|
|
|
|
|
var changeset_id = null;
|
|
|
|
var side = list.getDisplaySideFromHeader(origin);
|
|
|
|
if (side == 'right') {
|
|
|
|
changeset_id = this.getRightChangesetID();
|
|
|
|
} else {
|
|
|
|
changeset_id = this.getLeftChangesetID();
|
|
|
|
}
|
|
|
|
|
|
|
|
var is_new = false;
|
|
|
|
if (side == 'right') {
|
|
|
|
is_new = true;
|
|
|
|
} else if (this.getRightChangesetID() != this.getLeftChangesetID()) {
|
|
|
|
is_new = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
var data = {
|
|
|
|
origin: origin,
|
|
|
|
target: target,
|
|
|
|
number: src,
|
|
|
|
length: dst - src,
|
|
|
|
changesetID: changeset_id,
|
|
|
|
displaySide: side,
|
|
|
|
isNewFile: is_new
|
|
|
|
};
|
|
|
|
|
2020-05-14 00:27:11 +02:00
|
|
|
JX.copy(data, options || {});
|
|
|
|
|
2017-05-16 01:26:45 +02:00
|
|
|
var inline = new JX.DiffInline()
|
|
|
|
.setChangeset(this)
|
|
|
|
.bindToRange(data);
|
|
|
|
|
|
|
|
this._inlines.push(inline);
|
|
|
|
|
|
|
|
inline.create();
|
|
|
|
|
|
|
|
return inline;
|
|
|
|
},
|
|
|
|
|
2017-05-17 01:52:31 +02:00
|
|
|
newInlineReply: function(original, text) {
|
2017-05-16 01:35:06 +02:00
|
|
|
var inline = new JX.DiffInline()
|
|
|
|
.setChangeset(this)
|
|
|
|
.bindToReply(original);
|
|
|
|
|
|
|
|
this._inlines.push(inline);
|
|
|
|
|
2017-05-17 01:52:31 +02:00
|
|
|
inline.create(text);
|
2017-05-16 01:35:06 +02:00
|
|
|
|
|
|
|
return inline;
|
|
|
|
},
|
|
|
|
|
2017-05-16 00:03:30 +02:00
|
|
|
getInlineByID: function(id) {
|
2017-05-17 20:59:00 +02:00
|
|
|
return this._queryInline('id', id);
|
|
|
|
},
|
|
|
|
|
|
|
|
getInlineByPHID: function(phid) {
|
|
|
|
return this._queryInline('phid', phid);
|
|
|
|
},
|
|
|
|
|
|
|
|
_queryInline: function(field, value) {
|
2017-05-17 20:39:56 +02:00
|
|
|
// First, look for the inline in the objects we've already built.
|
2017-05-17 20:59:00 +02:00
|
|
|
var inline = this._findInline(field, value);
|
2017-05-17 20:39:56 +02:00
|
|
|
if (inline) {
|
|
|
|
return inline;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we haven't found a matching inline yet, rebuild all the inlines
|
|
|
|
// present in the document, then look again.
|
|
|
|
this._rebuildAllInlines();
|
2017-05-17 20:59:00 +02:00
|
|
|
return this._findInline(field, value);
|
2017-05-17 20:39:56 +02:00
|
|
|
},
|
2017-05-16 00:03:30 +02:00
|
|
|
|
2017-05-17 20:59:00 +02:00
|
|
|
_findInline: function(field, value) {
|
2017-05-16 00:03:30 +02:00
|
|
|
for (var ii = 0; ii < this._inlines.length; ii++) {
|
|
|
|
var inline = this._inlines[ii];
|
2017-05-17 20:59:00 +02:00
|
|
|
|
|
|
|
var target;
|
|
|
|
switch (field) {
|
|
|
|
case 'id':
|
|
|
|
target = inline.getID();
|
|
|
|
break;
|
|
|
|
case 'phid':
|
|
|
|
target = inline.getPHID();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (target == value) {
|
2017-05-16 00:03:30 +02:00
|
|
|
return inline;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return null;
|
2017-05-17 20:39:56 +02:00
|
|
|
},
|
|
|
|
|
2017-05-30 23:00:02 +02:00
|
|
|
getInlines: function() {
|
|
|
|
this._rebuildAllInlines();
|
|
|
|
return this._inlines;
|
|
|
|
},
|
|
|
|
|
2017-05-17 20:39:56 +02:00
|
|
|
_rebuildAllInlines: function() {
|
|
|
|
var rows = JX.DOM.scry(this._node, 'tr');
|
2018-02-09 01:55:54 +01:00
|
|
|
var ii;
|
|
|
|
for (ii = 0; ii < rows.length; ii++) {
|
2017-05-17 20:39:56 +02:00
|
|
|
var row = rows[ii];
|
|
|
|
if (this._getRowType(row) != 'comment') {
|
|
|
|
continue;
|
|
|
|
}
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
|
2017-05-17 20:39:56 +02:00
|
|
|
// As a side effect, this builds any missing inline objects and adds
|
|
|
|
// them to this Changeset's list of inlines.
|
|
|
|
this.getInlineForRow(row);
|
|
|
|
}
|
2017-05-17 21:51:29 +02:00
|
|
|
},
|
|
|
|
|
2018-02-09 01:55:54 +01:00
|
|
|
redrawFileTree: function() {
|
|
|
|
var inlines = this._inlines;
|
|
|
|
var done = [];
|
|
|
|
var undone = [];
|
|
|
|
var inline;
|
|
|
|
|
|
|
|
for (var ii = 0; ii < inlines.length; ii++) {
|
|
|
|
inline = inlines[ii];
|
|
|
|
|
|
|
|
if (inline.isDeleted()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Refine unusual inline comment client interactions
Summary: Ref T13513. Refine some inline behaviors, see test plan.
Test Plan:
- Edit a comment ("A"), type text ("AB"), cancel, edit.
- Old behavior: edit and undo states (wrong, and undo does not function).
- New behavior: edit state only.
- Edit a comment ("A"), type text ("AB"), cancel. Undo ("AB"), cancel. Edit.
- Old behavior: "AB" (wrong: you never submitted this text).
- New behavior: "A".
- Create a comment, type text, cancel.
- Old behavior: counter appears in filetree (wrong, comment is undo-able but should not be counted).
- New behavior: no counter.
- Cancel editing an empty comment with no text.
- Old behavior: Something buggy -- undo, I think?
- New behavior: it just vanishes (correct behavior).
Maniphest Tasks: T13513
Differential Revision: https://secure.phabricator.com/D21212
2020-05-04 18:22:23 +02:00
|
|
|
if (inline.isUndo()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-02-09 01:55:54 +01:00
|
|
|
if (inline.isSynthetic()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (inline.isEditing()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!inline.getID()) {
|
|
|
|
// These are new comments which have been cancelled, and do not
|
|
|
|
// count as anything.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (inline.isDraft()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!inline.isDone()) {
|
|
|
|
undone.push(inline);
|
|
|
|
} else {
|
|
|
|
done.push(inline);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var total = done.length + undone.length;
|
|
|
|
|
|
|
|
var hint;
|
|
|
|
var is_visible;
|
|
|
|
var is_completed;
|
|
|
|
if (total) {
|
|
|
|
if (done.length) {
|
|
|
|
hint = [done.length, '/', total];
|
|
|
|
} else {
|
|
|
|
hint = total;
|
|
|
|
}
|
|
|
|
is_visible = true;
|
|
|
|
is_completed = (done.length == total);
|
|
|
|
} else {
|
|
|
|
hint = '-';
|
|
|
|
is_visible = false;
|
|
|
|
is_completed = false;
|
|
|
|
}
|
|
|
|
|
2020-04-21 23:27:27 +02:00
|
|
|
var node = this.getPathView().getInlineNode();
|
|
|
|
|
|
|
|
JX.DOM.setContent(node, hint);
|
|
|
|
|
|
|
|
JX.DOM.alterClass(node, 'diff-tree-path-inlines-visible', is_visible);
|
|
|
|
JX.DOM.alterClass(node, 'diff-tree-path-inlines-completed', is_completed);
|
2018-02-09 01:55:54 +01:00
|
|
|
},
|
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
_onClickHeader: function(e) {
|
2020-05-08 15:36:31 +02:00
|
|
|
// If the user clicks the actual path name text, don't count this as
|
|
|
|
// a selection action: we want to let them select the path.
|
|
|
|
var path_name = e.getNode('changeset-header-path-name');
|
|
|
|
if (path_name) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-05-14 21:49:29 +02:00
|
|
|
// Don't allow repeatedly clicking a header to begin a "select word" or
|
|
|
|
// "select line" operation.
|
|
|
|
if (e.getType() === 'selectstart') {
|
|
|
|
e.kill();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-05-14 20:43:55 +02:00
|
|
|
// NOTE: Don't prevent or kill the event. If the user has text selected,
|
|
|
|
// clicking a header should clear the selection (and dismiss any inline
|
|
|
|
// context menu, if one exists) as clicking elsewhere in the document
|
|
|
|
// normally would.
|
2020-04-23 17:50:46 +02:00
|
|
|
|
|
|
|
if (this._isSelected) {
|
|
|
|
this.getChangesetList().selectChangeset(null);
|
|
|
|
} else {
|
|
|
|
this.select(false);
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2017-05-17 21:51:29 +02:00
|
|
|
toggleVisibility: function() {
|
2020-04-22 22:13:15 +02:00
|
|
|
this.setVisible(!this._visible);
|
|
|
|
|
|
|
|
var attrs = {
|
|
|
|
hidden: this.isVisible() ? 0 : 1,
|
|
|
|
discard: 1
|
|
|
|
};
|
|
|
|
|
|
|
|
var workflow = this._newReloadWorkflow(attrs)
|
|
|
|
.setHandler(JX.bag);
|
|
|
|
|
|
|
|
this._startContentWorkflow(workflow);
|
|
|
|
},
|
|
|
|
|
|
|
|
setVisible: function(visible) {
|
|
|
|
this._visible = visible;
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var diff = this._getDiffNode();
|
|
|
|
var options = this._getViewButtonNode();
|
|
|
|
var show = this._getShowButtonNode();
|
2017-05-17 21:51:29 +02:00
|
|
|
|
|
|
|
if (this._visible) {
|
|
|
|
JX.DOM.show(diff);
|
2020-04-23 17:50:46 +02:00
|
|
|
JX.DOM.show(options);
|
|
|
|
JX.DOM.hide(show);
|
2017-05-17 21:51:29 +02:00
|
|
|
} else {
|
|
|
|
JX.DOM.hide(diff);
|
2020-04-23 17:50:46 +02:00
|
|
|
JX.DOM.hide(options);
|
|
|
|
JX.DOM.show(show);
|
|
|
|
|
|
|
|
if (this._viewMenu) {
|
|
|
|
this._viewMenu.close();
|
|
|
|
}
|
2017-05-17 21:51:29 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
JX.Stratcom.invoke('resize');
|
2020-04-22 22:13:15 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var node = this._node;
|
|
|
|
JX.DOM.alterClass(node, 'changeset-content-hidden', !this._visible);
|
|
|
|
|
2020-04-22 22:13:15 +02:00
|
|
|
this.getPathView().setIsHidden(!this._visible);
|
2017-05-17 21:51:29 +02:00
|
|
|
},
|
2017-05-16 00:03:30 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
setIsSelected: function(is_selected) {
|
|
|
|
this._isSelected = !!is_selected;
|
2017-05-18 20:54:58 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var node = this._node;
|
|
|
|
JX.DOM.alterClass(node, 'changeset-selected', this._isSelected);
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
return this;
|
|
|
|
},
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
_getDiffNode: function() {
|
|
|
|
if (!this._diffNode) {
|
|
|
|
this._diffNode = JX.DOM.find(this._node, 'table', 'differential-diff');
|
|
|
|
}
|
|
|
|
return this._diffNode;
|
|
|
|
},
|
|
|
|
|
|
|
|
_getViewButtonNode: function() {
|
|
|
|
if (!this._viewButtonNode) {
|
|
|
|
this._viewButtonNode = JX.DOM.find(
|
|
|
|
this._node,
|
|
|
|
'a',
|
|
|
|
'differential-view-options');
|
|
|
|
}
|
|
|
|
return this._viewButtonNode;
|
|
|
|
},
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
_getShowButtonNode: function() {
|
|
|
|
if (!this._showButtonNode) {
|
|
|
|
var pht = this.getChangesetList().getTranslations();
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var show_button = new JX.PHUIXButtonView()
|
|
|
|
.setIcon('fa-angle-double-down')
|
|
|
|
.setText(pht('Show Changeset'))
|
|
|
|
.setColor('grey');
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var button_node = show_button.getNode();
|
|
|
|
this._getViewButtonNode().parentNode.appendChild(button_node);
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
var onshow = JX.bind(this, this._onClickShowButton);
|
|
|
|
JX.DOM.listen(button_node, 'click', null, onshow);
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
this._showButtonNode = button_node;
|
2017-05-17 21:51:29 +02:00
|
|
|
}
|
2020-04-23 17:50:46 +02:00
|
|
|
return this._showButtonNode;
|
|
|
|
},
|
2017-05-17 21:51:29 +02:00
|
|
|
|
2020-04-23 17:50:46 +02:00
|
|
|
_onClickShowButton: function(e) {
|
|
|
|
e.prevent();
|
2020-05-08 15:36:31 +02:00
|
|
|
|
|
|
|
// We're always showing the changeset, but want to make sure the state
|
|
|
|
// change is persisted on the server.
|
|
|
|
this.toggleVisibility();
|
2020-04-23 17:50:46 +02:00
|
|
|
},
|
|
|
|
|
|
|
|
isVisible: function() {
|
|
|
|
return this._visible;
|
2017-05-17 21:51:29 +02:00
|
|
|
},
|
|
|
|
|
2020-04-21 18:56:30 +02:00
|
|
|
getPathView: function() {
|
|
|
|
if (!this._pathView) {
|
2020-04-21 22:02:36 +02:00
|
|
|
var view = new JX.DiffPathView()
|
2020-04-21 18:56:30 +02:00
|
|
|
.setChangeset(this)
|
2020-04-22 19:56:09 +02:00
|
|
|
.setPath(this._pathParts)
|
|
|
|
.setIsLowImportance(this._isLowImportance)
|
2020-04-22 22:13:15 +02:00
|
|
|
.setIsOwned(this._isOwned)
|
|
|
|
.setIsLoading(this._isLoading);
|
2020-04-21 22:02:36 +02:00
|
|
|
|
|
|
|
view.getIcon()
|
2020-04-22 17:11:45 +02:00
|
|
|
.setIcon(this._pathIconIcon)
|
|
|
|
.setColor(this._pathIconColor);
|
2020-04-21 22:02:36 +02:00
|
|
|
|
|
|
|
this._pathView = view;
|
2020-04-21 18:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return this._pathView;
|
|
|
|
},
|
|
|
|
|
|
|
|
select: function(scroll) {
|
|
|
|
this.getChangesetList().selectChangeset(this, scroll);
|
|
|
|
return this;
|
2017-05-17 21:51:29 +02:00
|
|
|
}
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
},
|
|
|
|
|
|
|
|
statics: {
|
|
|
|
getForNode: function(node) {
|
|
|
|
var data = JX.Stratcom.getData(node);
|
|
|
|
if (!data.changesetViewManager) {
|
2017-05-08 18:52:16 +02:00
|
|
|
data.changesetViewManager = new JX.DiffChangeset(node);
|
Consolidate changeset rendering logic
Summary:
Ref T5179. Currently, all the changeset rendering logic is in the "populate" behavior, and a lot of it comes in via configuration and is hard to get at.
Instead, surface an object which can control it, and which other behaviors can access more easily.
In particular, this allows us to add a "Load/Reload" item to the view options menu, which would previously have been very challenging.
Load/Reload isn't useful on its own, but is a step away from "Show whitespace as...", "Highlight as...", "Show tabtops as...", "View Unified", "View Side-By-Side", etc.
Test Plan:
- Viewed Differential.
- Viewed Diffusion.
- Viewed large changesets, clicked "Load".
- Used "Load" and "Reload" from view options menu.
- Loaded all changes in a large diff, verified "Load" and TOC clicks take precedence over other content loads.
- Played with content stability stuff.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5179
Differential Revision: https://secure.phabricator.com/D9286
2014-05-25 16:13:22 +02:00
|
|
|
}
|
|
|
|
return data.changesetViewManager;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|