[webkit-reviews] review denied: [Bug 197973] 'analysis-task-configurator-pane' does not update when switch from one analysis task to another : [Attachment 370328] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed May 22 19:55:23 PDT 2019
Ryosuke Niwa <rniwa at webkit.org> has denied Zhifei Fang
<zhifei_fang at apple.com>'s request for review:
Bug 197973: 'analysis-task-configurator-pane' does not update when switch from
one analysis task to another
Attachment 370328: Patch
--- Comment #8 from Ryosuke Niwa <rniwa at webkit.org> ---
Comment on attachment 370328
View in context: https://bugs.webkit.org/attachment.cgi?id=370328&action=review
Okay, now I understand what you're trying to do but I don't think the fix is
> + Currently on analysis-task-page we check if his children
> + custom-configuration-test-group-form already have been set test
groups, if so
I don't really follow what you're trying to say here.
Where / when do we check if custom-configuration-test-group-form already have
test groups set?
> + we don't update the new test groups
> + * browser-tests/analysis-task-page-tests.js: Added a unittest for
analysis task page.
Need a blank line between the long description and file lists.
> + (CustomAnalysisTaskConfigurator.prototype.setCommitSets): We will
> + to find the comparisonRepositoryGroup based on the comparison commit
> + set, for now it doesn't make any difference since baseline and
> + comparison use the same repositoryGroup, however this could be a
Why? What potential issues would that cause?
In general, we strive to add "why" comments instead of "what" comments.
We can see what we're doing from the code,
what would be valuable is explaining why we're doing what we're doing.
A better thing to say would be something like this:
Fix a bug that we were finding the repository group using the baseline's commit
set instead of comparison's
This should definitely be testable. It should pick a wrong repository group for
the comparison without this fix.
> + (AnalysisTaskConfiguratorPane.prototype.setTestGroups): When we
> + go to task A, we will set the form's commit sets, then we redirect
> + task B, we check if we already set the form's commit set, we already
> + have did so, then we don't update the test groups
Okay, this is the kind of description we need below "Reviewed by NOBODY".
We can make it less wordy though.
e.g. The bug was caused by AnalysisTaskConfiguratorPane's setTestGroups
not updating the configuration when the commit sets are already set for another
> + const taskConfiguratorPane = new
This test file is called analysis-task-page-tests.js, then create
See browser-tests/test-group-result-page-tests.js for example.
> + configurator.render();
This is not correct. You should never differently call "render" method on a
Instead, enqueue the component to render and use waitForComponentsToRender to
wait for it to render.
But really, if we should be enqueuing to render the analysis task page instead.
> + expect(configurator.tests()._id).to.be(testGroup1.test()._id);
Don't assert the private states of a class like this. This will make the future
> - if (!form.hasCommitSets() && currentGroup)
> + if (currentGroup)
This isn't right. This fix would re-set test & platform in the configuration
pane whenever a different test group is picked in UI.
It's a feature that the configuration pane retains the manually picked test &
platform even when the user picks another test group.
Please add a test for that.
We probably need to check if !form.hasCommitSets() or analysis task of the
current group has changed.
More information about the webkit-reviews